[gentoo-dev] Re: Prefix bootstrap script maintainability (Was: No more stable keywords for Games)

[R0b0t1]

Hello friends!

On Sun, Nov 19, 2017 at 6:54 PM, Benda Xu  wrote:
> Greetings R0b0t1,
>
> R0b0t1  writes:
>
>> It is one thing to say that contributions to the main Portage tree
>> require some standards to be upheld, but these standards do not seem
>> to be applied consistently. For example, crossdev, genkernel, and the
>> bootstrap-prefix and bootstrap-rap scripts are more or less
>> unmaintainable disasters.
>> [...]
>> and the bootstrap scripts are poorly explained with no extant
>> documentation and a workflow that does not clearly fit into Gentoo (or
>> more properly Portage) development at large.
>
> As one of the maintainers of the bootstrap-prefix (and bootstrap-rap), I
> acknowledge that the script is a result of accumulated contributions
> from multiple people, with rounds of refactorizations in the past
> several years. But it is well understood and maintainable.
>
> I would like to remind you that, the script is a reflection of the
> instrinsic complexity to compile a workable Gentoo from zero, in a wild
> variety of environments from handhold embedded devices to top 10
> supercomputers, from GNU/Linux, MacOS to Solaris/OpenIndiana and Cygwin.
>

That is fine, but I am more talking about the burden of trying to
understand what is going on. Nowhere is there a simple list of steps
that the bootstrap scripts take. The code is sparsely commented and
intent is not readily inferred from context. Some of this is related
to the packages in question, and I can not expect the scripts to e.g.
summarize the autotools options passed to the respective software, but
justification for why what is taking place is taking place should have
been a priority.

The typical response of "read the code" (which I have read more than a
few places) indicates to me that someone does not value my time and
has not bothered to remember what they have done, or why. Besides the
insult to future contributors this train of thought reflects poorly on
the quality of the author's work and the esteem with which they hold
the fruits of their labor.

I feel this manifests as the original developers being unlikely to
contribute because they have lost track of the various interacting
components and would need to invest a substantial amount of time in
re-understanding their own work. There are other projects where I have
observed the main authors undertake what appear to be, at first
glance, very technical changes due to an offhand comment by a mailing
list user.

These projects all seem to have been well documented.

> Don't be pissed off if it couldn't be hacked in several hours to be
> ported to ppc64.  That's life: anything worth doing will not be easy.
>

Understanding an existing codebase should not be a technical
challenge. I had to resort to reimplementing all of the steps myself,
in part to understand if they were done properly in the first place.

In the case of the bootstrap scripts, minor problems are very hard to
diagnose because of limited feedback given, and the difficulty of
integrating what feedback is available into the overall setup process.

> For the standards and documentation, yes, the recommended workflow had
> better be carved into stone.  That's where things should be improved.
>

Unfortunately these are things that the original authors should
produce. Experience has shown me that documentation written by
ancillary contributors that do not have deep experience with the code
base is poor.

Respectfully,
 R0b0t1

Re: [gentoo-dev] Re: No more stable keywords for Games

[NP-Hardass]

On 11/19/2017 01:45 PM, Philip Webb wrote:
> 171119 James Le Cuirot wrote:
>> On Sun, 19 Nov 2017 08:50:20 -0500
>> Philip Webb  wrote:
>>> 171118 David Seifert wrote:
 As the Games team does not have enough manpower to keep tabs on all
 games packages, we have dropped all games-* ebuilds to unstable
 keywords (modulo those required by stable non-games packages).
>>> Isn't this overkill in the absence of widespread bug reports for games ?
>>> 'Stable' doesn't mean well-maintained,
>>> but in the tree for some time & no serious bug reports.
>> There are plenty of bug reports for games.
> 
> What percentage of games pkgs have bugs ?
> 
> Eg I amuse myself with  games-puzzle/sgt-puzzles ;
> it is maintained upstream with regular updates.
> The only unresolved bug appears to be 602696
> which relates to version 20161207, which is no longer in the tree :
> why is the bug still marked 'confirmed' ?  Shouldn't it be 'resolved' ?
> 
> What justification is there for marking this pkg 'unstable' ?
> My guess is that there are other games pkgs with no valid bug.
> 
> Marking all games 'unstable' still seems to be overkill.
> 

I am going to add my +1 to overkill.

Firstly, we need to reclarify...  Games Project doesn't have exclusive
control over the games-* categories...  So, this should only apply to
packages that the games project controls.  The original message doesn't
really convey that.

Secondly, if the issue is Games Project, then if there is another
maintainer involved in maintaining a package, then the decision to drop
keywords should be mutual with the other maintainer, or Games should
consider dropping maintainership in deference to the other, active
maintainer.

Which brings me to the third point...  If the Games Project admits that
it doesn't have the manpower to maintain things, and is forcibly
dropping all stable keywords as part of their non-maintenance, I think
they should adopt a policy of allowing anyone to come in and take over
(and potentially remove them) from the package.  Someone else should be
able to vouch for and work for the stability and quality of a package
and take responsibility for it.  By Games Project being in the metadata,
it gives the false impression that they are responsible.

I'm the maintainer of games-puzzle/sgt-puzzles and while Games Project
is in the metadata, I'm really the primary maintainer.  I don't want my
stable keywords dropped.  You are welcome to drop your project from the
metadata, but please leave my package, and all those that others are
responsible for, alone.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged

[heroxbd]

From: Benda Xu 

Thanks again.  I will take your original suggestion.

  enewgroup and enewuser does not apply when executed as a normal
  user, e.g. under Gentoo Prefix.
---
 eclass/user.eclass | 8 
 1 file changed, 8 insertions(+)

diff --git a/eclass/user.eclass b/eclass/user.eclass
index 86bcd282479..76a622df698 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -103,6 +103,10 @@ egetent() {
 # Default uid is (pass -1 for this) next available, default shell is
 # /bin/false, default homedir is /dev/null, and there are no default groups.
 enewuser() {
+   if [[ ${EUID} != 0 ]] ; then
+   einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
+   return 0
+   fi
_assert_pkg_ebuild_phase ${FUNCNAME}
 
# get the username
@@ -262,6 +266,10 @@ enewuser() {
 # do the rest.  You may specify the gid for the group or allow the group to
 # allocate the next available one.
 enewgroup() {
+   if [[ ${EUID} != 0 ]] ; then
+   einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
+   return 0
+   fi
_assert_pkg_ebuild_phase ${FUNCNAME}
 
# get the group
-- 
2.15.0

Re: [gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged

[M. J. Everitt]

On 20/11/17 03:38, hero...@gentoo.org wrote:
> From: Benda Xu 
>
> Thanks MJ, how about "Unprivileged to execute"? Less bytes.
>
>   enewgroup and enewuser does not apply when executed as a normal
>   user, e.g. under Gentoo Prefix.
> ---
>  eclass/user.eclass | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/eclass/user.eclass b/eclass/user.eclass
> index 86bcd282479..8ff06935277 100644
> --- a/eclass/user.eclass
> +++ b/eclass/user.eclass
> @@ -103,6 +103,10 @@ egetent() {
>  # Default uid is (pass -1 for this) next available, default shell is
>  # /bin/false, default homedir is /dev/null, and there are no default groups.
>  enewuser() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Unprivileged to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the username
> @@ -262,6 +266,10 @@ enewuser() {
>  # do the rest.  You may specify the gid for the group or allow the group to
>  # allocate the next available one.
>  enewgroup() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Unprivileged to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the group
That's rather strange English .. perhaps "Unprivileged: cannot execute..."

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Strip features via profile.bashrc

[William L. Thomson Jr.]

On Sun, 19 Nov 2017 22:27:26 -0500
Mike Gilbert  wrote:
>
> FEATURES gets processed by portage too early for bashrc settings to
> have any effect.

Glad to have that confirmed, as that is what I experienced.
Feel like I was in this commercial...
https://www.ispot.tv/ad/wlDi/directv-head-bang
 
> I do not think there is any equivalent to /etc/portage/package.env
> that can be defined in profiles.

Great thanks for confirming!

> I do not see any existing bug asking for this enhancement, so you
> could probably file a new one.

Will do, though I haven't had much luck in my profiles features
request. Sets went no where quick... Maybe this will have better luck!
https://bugs.gentoo.org/638196

-- 
William L. Thomson Jr.

[gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged

[heroxbd]

From: Benda Xu 

Thanks MJ, how about "Unprivileged to execute"? Less bytes.

  enewgroup and enewuser does not apply when executed as a normal
  user, e.g. under Gentoo Prefix.
---
 eclass/user.eclass | 8 
 1 file changed, 8 insertions(+)

diff --git a/eclass/user.eclass b/eclass/user.eclass
index 86bcd282479..8ff06935277 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -103,6 +103,10 @@ egetent() {
 # Default uid is (pass -1 for this) next available, default shell is
 # /bin/false, default homedir is /dev/null, and there are no default groups.
 enewuser() {
+   if [[ ${EUID} != 0 ]] ; then
+   einfo "Unprivileged to execute ${FUNCNAME[0]}"
+   return 0
+   fi
_assert_pkg_ebuild_phase ${FUNCNAME}
 
# get the username
@@ -262,6 +266,10 @@ enewuser() {
 # do the rest.  You may specify the gid for the group or allow the group to
 # allocate the next available one.
 enewgroup() {
+   if [[ ${EUID} != 0 ]] ; then
+   einfo "Unprivileged to execute ${FUNCNAME[0]}"
+   return 0
+   fi
_assert_pkg_ebuild_phase ${FUNCNAME}
 
# get the group
-- 
2.15.0

Re: [gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged.

[M. J. Everitt]

On 20/11/17 03:25, hero...@gentoo.org wrote:
> From: Benda Xu 
>
>   enewgroup and enewuser does not apply when executed as a normal
>   user, e.g. under Gentoo Prefix.
> ---
>  eclass/user.eclass | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/eclass/user.eclass b/eclass/user.eclass
> index 86bcd282479..82ccc1100ac 100644
> --- a/eclass/user.eclass
> +++ b/eclass/user.eclass
> @@ -103,6 +103,10 @@ egetent() {
>  # Default uid is (pass -1 for this) next available, default shell is
>  # /bin/false, default homedir is /dev/null, and there are no default groups.
>  enewuser() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Donot have enough privilege to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the username
> @@ -262,6 +266,10 @@ enewuser() {
>  # do the rest.  You may specify the gid for the group or allow the group to
>  # allocate the next available one.
>  enewgroup() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Donot have enough privilege to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the group
s/Donot have enough privilege/Insufficient privileges/ or "Needs root"

MJE



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [RFC, PATCH] db.eclass: support Prefix

[heroxbd]

From: Benda Xu 

  ROOT and D are replaced with EROOT and ED.
---
 eclass/db.eclass | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/eclass/db.eclass b/eclass/db.eclass
index c46c431ea9c..0c0d0ef14cd 100644
--- a/eclass/db.eclass
+++ b/eclass/db.eclass
@@ -17,7 +17,8 @@ DEPEND="test? ( >=dev-lang/tcl-8.4 )"
 RDEPEND=""
 
 db_fix_so() {
-   LIB="${ROOT}/usr/$(get_libdir)"
+   has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}"
+   LIB="${EROOT}/usr/$(get_libdir)"
 
cd "${LIB}"
 
@@ -50,7 +51,7 @@ db_fix_so() {
 
# do the same for headers now
# but since there are only two of them, just overwrite them
-   cd "${ROOT}"/usr/include
+   cd "${EROOT}"/usr/include
target=`find . -maxdepth 1 -type d -name 'db[0-9]*' | sort -n |cut -d/ 
-f2- | tail -n1`
if [ -n "${target}" ] && [ -e "${target}/db.h" ] && ( ! [[ -e db.h ]] 
|| [[ -h db.h ]] ); then
einfo "Creating db.h symlinks to ${target}"
@@ -67,19 +68,21 @@ db_fix_so() {
 }
 
 db_src_install_doc() {
+   has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
# not everybody wants this wad of documentation as it is primarily API 
docs
if use doc; then
dodir /usr/share/doc/${PF}/html
-   mv "${D}"/usr/docs/* "${D}"/usr/share/doc/${PF}/html/
-   rm -rf "${D}"/usr/docs
+   mv "${ED}"/usr/docs/* "${ED}"/usr/share/doc/${PF}/html/
+   rm -rf "${ED}"/usr/docs
else
-   rm -rf "${D}"/usr/docs
+   rm -rf "${ED}"/usr/docs
fi
 
db_src_install_examples
 }
 
 db_src_install_examples() {
+   has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
if use examples ; then
local langs="c cxx stl"
[[ "${IUSE/java}" != "${IUSE}" ]] \
@@ -90,15 +93,16 @@ db_src_install_examples() {
src="${S}/../examples_${i}/"
if [ -f "${src}" ]; then
dodir "${destdir}"
-   cp -ra "${src}" "${D}${destdir}/"
+   cp -ra "${src}" "${ED}${destdir}/"
fi
done
fi
 }
 
 db_src_install_usrbinslot() {
+   has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
# slot all program names to avoid overwriting
-   for fname in "${D}"/usr/bin/db*
+   for fname in "${ED}"/usr/bin/db*
do
dn="$(dirname "${fname}")"
bn="$(basename "${fname}")"
@@ -109,18 +113,20 @@ db_src_install_usrbinslot() {
 }
 
 db_src_install_headerslot() {
+   has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
# install all headers in a slotted location
dodir /usr/include/db${SLOT}
-   mv "${D}"/usr/include/*.h "${D}"/usr/include/db${SLOT}/
+   mv "${ED}"/usr/include/*.h "${ED}"/usr/include/db${SLOT}/
 }
 
 db_src_install_usrlibcleanup() {
-   LIB="${D}/usr/$(get_libdir)"
+   has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
+   LIB="${ED}/usr/$(get_libdir)"
# Clean out the symlinks so that they will not be recorded in the
# contents (bug #60732)
 
-   if [ "${D}" = "" ]; then
-   die "Calling clean_links while \$D not defined"
+   if [ "${ED}" = "" ]; then
+   die "Calling clean_links while \$ED not defined"
fi
 
if [ -e "${LIB}"/libdb.a ] && [ ! -e "${LIB}"/libdb-${SLOT}.a ]; then
@@ -139,7 +145,7 @@ db_src_install_usrlibcleanup() {
find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*a' -exec rm \{} \;
 
rm -f \
-   "${D}"/usr/include/{db,db_185}.h \
+   "${ED}"/usr/include/{db,db_185}.h \
"${LIB}"/libdb{,_{cxx,sql,stl,java,tcl}}.a
 }
 
-- 
2.15.0

Re: [gentoo-dev] Strip features via profile.bashrc

[Mike Gilbert]

On Sun, Nov 19, 2017 at 9:57 PM, William L. Thomson Jr.
 wrote:
> I am trying to replicate like /etc/portage/package.env type function.
> For some packages I had FEATURES="-buildpkg". I cannot seem to
> replicate this what so ever with profile.bashrc.
>
> Not sure how via a profile in an overlay/tree, not /etc/portage, one
> can add/remove features. I do not seem to have this problem with other
> stuff. I_KNOW_WHAT_I_AM_DOING works for skipping pre-merge checks.
> I am also able to add CFLAGS/CXXFLAGS. Which I noticed were being added
> like 4 times, so I added in a phase check/hook.
>
> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/profiles/linux/amd64/profile.bashrc
>
> For some reason I cannot seem to add or remove FEATURES. I can see them
> in the shell. But they seem to have no effect. At least with regard to
> buildpkg FEATURE.
>
> phase: setup features: assume-digests binpkg-logs buildpkg ...
> phase: setup features: assume-digests binpkg-logs buildpkg ...
>
> In this case its removed, but still makes a binpkg.
>
> phase: package features: assume-digests binpkg-logs
> config-protect-if-modified ...
>
> .Doesn't show but in my output there is a gap, 2 spaces
> where it was. I can see the profile.bash being processed and doing its
> thing.
>
> I have tried export and set, neither have effect. Even when replaced
> with -buildpkg. Seems like make.conf is sourced or something for that.
> I do not think I am setting it to late. I cannot seem to set it for the
> build env.
>
> Any way to do this? A bug?

FEATURES gets processed by portage too early for bashrc settings to
have any effect.

I do not think there is any equivalent to /etc/portage/package.env
that can be defined in profiles.

I do not see any existing bug asking for this enhancement, so you
could probably file a new one.

[gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged.

[heroxbd]

From: Benda Xu 

  enewgroup and enewuser does not apply when executed as a normal
  user, e.g. under Gentoo Prefix.
---
 eclass/user.eclass | 8 
 1 file changed, 8 insertions(+)

diff --git a/eclass/user.eclass b/eclass/user.eclass
index 86bcd282479..82ccc1100ac 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -103,6 +103,10 @@ egetent() {
 # Default uid is (pass -1 for this) next available, default shell is
 # /bin/false, default homedir is /dev/null, and there are no default groups.
 enewuser() {
+   if [[ ${EUID} != 0 ]] ; then
+   einfo "Donot have enough privilege to execute ${FUNCNAME[0]}"
+   return 0
+   fi
_assert_pkg_ebuild_phase ${FUNCNAME}
 
# get the username
@@ -262,6 +266,10 @@ enewuser() {
 # do the rest.  You may specify the gid for the group or allow the group to
 # allocate the next available one.
 enewgroup() {
+   if [[ ${EUID} != 0 ]] ; then
+   einfo "Donot have enough privilege to execute ${FUNCNAME[0]}"
+   return 0
+   fi
_assert_pkg_ebuild_phase ${FUNCNAME}
 
# get the group
-- 
2.15.0

[gentoo-dev] Strip features via profile.bashrc

[William L. Thomson Jr.]

I am trying to replicate like /etc/portage/package.env type function.
For some packages I had FEATURES="-buildpkg". I cannot seem to
replicate this what so ever with profile.bashrc.

Not sure how via a profile in an overlay/tree, not /etc/portage, one
can add/remove features. I do not seem to have this problem with other
stuff. I_KNOW_WHAT_I_AM_DOING works for skipping pre-merge checks.
I am also able to add CFLAGS/CXXFLAGS. Which I noticed were being added
like 4 times, so I added in a phase check/hook.

https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/profiles/linux/amd64/profile.bashrc

For some reason I cannot seem to add or remove FEATURES. I can see them
in the shell. But they seem to have no effect. At least with regard to
buildpkg FEATURE.

phase: setup features: assume-digests binpkg-logs buildpkg ...
phase: setup features: assume-digests binpkg-logs buildpkg ...

In this case its removed, but still makes a binpkg.

phase: package features: assume-digests binpkg-logs
config-protect-if-modified ...

.Doesn't show but in my output there is a gap, 2 spaces
where it was. I can see the profile.bash being processed and doing its
thing. 

I have tried export and set, neither have effect. Even when replaced
with -buildpkg. Seems like make.conf is sourced or something for that.
I do not think I am setting it to late. I cannot seem to set it for the
build env.

Any way to do this? A bug?

-- 
William L. Thomson Jr.


pgpBoa0TfVu_m.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] NEWS item for games destabling

[Benda Xu]

David Seifert  writes:

> As the Games team does not have enough manpower to keep tabs on all
> games packages, we have dropped all games-* ebuilds to unstable
> KEYWORDS (modulo those required by stable non-games packages). 

"modulo" is too mathematical to be understood by a general user.

[gentoo-dev] Prefix bootstrap script maintainability (Was: No more stable keywords for Games)

[Benda Xu]

Greetings R0b0t1,

R0b0t1  writes:

> It is one thing to say that contributions to the main Portage tree
> require some standards to be upheld, but these standards do not seem
> to be applied consistently. For example, crossdev, genkernel, and the
> bootstrap-prefix and bootstrap-rap scripts are more or less
> unmaintainable disasters.
> [...]
> and the bootstrap scripts are poorly explained with no extant
> documentation and a workflow that does not clearly fit into Gentoo (or
> more properly Portage) development at large.

As one of the maintainers of the bootstrap-prefix (and bootstrap-rap), I
acknowledge that the script is a result of accumulated contributions
from multiple people, with rounds of refactorizations in the past
several years. But it is well understood and maintainable.

I would like to remind you that, the script is a reflection of the
instrinsic complexity to compile a workable Gentoo from zero, in a wild
variety of environments from handhold embedded devices to top 10
supercomputers, from GNU/Linux, MacOS to Solaris/OpenIndiana and Cygwin.

Don't be pissed off if it couldn't be hacked in several hours to be
ported to ppc64.  That's life: anything worth doing will not be easy.


For the standards and documentation, yes, the recommended workflow had
better be carved into stone.  That's where things should be improved.

Good luck
Benda

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2017-11-19 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2017-11-19 23:59 UTC.

Removals:
dev-python/skype4py20171114-23:01 asturm 
9fd953b2870
games-rpg/nwmouse  20171114-00:18 wizardedit 
310e73fc1d9
games-rpg/nwmovies 20171114-00:18 wizardedit 
310e73fc1d9
games-rpg/nwn  20171114-00:18 wizardedit 
310e73fc1d9
games-rpg/nwn-cep  20171114-00:18 wizardedit 
310e73fc1d9
games-rpg/nwn-data 20171114-00:18 wizardedit 
310e73fc1d9
games-rpg/nwn-penultima20171114-00:18 wizardedit 
310e73fc1d9
games-rpg/nwn-penultimarerolled20171114-00:18 wizardedit 
310e73fc1d9
games-rpg/nwn-shadowlordsdreamcatcherdemon 20171114-00:18 wizardedit 
310e73fc1d9
kde-misc/kbiff 20171114-23:01 asturm 
9fd953b2870
kde-misc/kover 20171114-23:01 asturm 
9fd953b2870
media-gfx/kfax 20171114-23:01 asturm 
9fd953b2870
media-sound/k4guitune  20171114-23:01 asturm 
9fd953b2870
media-sound/kenvy2420171114-23:01 asturm 
9fd953b2870
media-sound/kmidimon   20171114-23:01 asturm 
9fd953b2870
media-sound/kradio 20171114-23:01 asturm 
9fd953b2870
media-sound/skype-call-recorder20171114-23:01 asturm 
9fd953b2870
media-sound/waheela20171114-23:01 asturm 
9fd953b2870
media-video/loopy  20171114-23:01 asturm 
9fd953b2870
net-im/skype   20171115-07:36 asturm 
d7c8833dec2
net-im/skypetab-ng 20171114-23:01 asturm 
9fd953b2870
net-p2p/kmldonkey  20171114-23:01 asturm 
9fd953b2870

Additions:
app-emacs/atomic-chrome20171119-21:20 ulm
4461bf4001e
app-emacs/websocket20171119-20:58 ulm
7dd6db87fd1
dev-db/pspg20171116-15:32 titanofold 
76fcf5d6c72
dev-perl/Time-Monotonic20171116-23:04 dilfridge  
1176ee70e49
dev-python/collective-checkdocs20171113-03:07 prometheanfire 
c29de60372d
dev-python/funcy   20171119-20:46 tupone 
9445e753d28
media-gfx/sigal20171112-20:57 jstein 
fb22e641613
net-im/bitlbee-facebook20171117-17:06 soap   
61413c4e368
net-im/signal-desktop-bin  20171119-13:24 soap   
a60d22e460d
net-misc/nyx   20171113-05:37 blueness   
c49fa4f01ef
sci-biology/HTSeq  20171116-11:39 soap   
cd2d3189dad
sci-biology/kallisto   20171116-13:15 soap   
3dcd860e419
sci-biology/STAR   20171116-12:32 soap   
acd76729254
sys-auth/libnss-nis20171117-19:13 dilfridge  
7cf52c674ca
www-servers/civetweb   20171113-06:22 zmedico
5da658803c6

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
net-im/skype,removed,asturm,20171115-07:36,d7c8833dec2
dev-python/skype4py,removed,asturm,20171114-23:01,9fd953b2870
kde-misc/kbiff,removed,asturm,20171114-23:01,9fd953b2870
kde-misc/kover,removed,asturm,20171114-23:01,9fd953b2870
media-gfx/kfax,removed,asturm,20171114-23:01,9fd953b2870
media-sound/k4guitune,removed,asturm,20171114-23:01,9fd953b2870
media-sound/kenvy24,removed,asturm,20171114-23:01,9fd953b2870
media-sound/kmidimon,removed,asturm,20171114-23:01,9fd953b2870
media-sound/kradio,removed,asturm,20171114-23:01,9fd953b2870
media-sound/skype-call-recorder,removed,asturm,20171114-23:01,9fd953b2870
media-sound/waheela,removed,asturm,20171114-23:01,9fd953b2870
media-video/loopy,removed,asturm,20171114-23:01,9fd953b2870
net-im/skypetab-ng,removed,asturm,20171114-23:01,9fd953b2870
net-p2p/kmldonkey,removed,asturm,20171114-23:01,9fd953b2870
games-rpg/nwmouse,removed,wizardedit,20171114-00:18,310e73fc1d9
games-rpg/nwmovies,removed,wizardedit,20171114-00:18,310e73fc1d9
games-rpg/nwn-cep,removed,wizardedit,20171114-00:18,310e73fc1d9
games-rpg/nwn-data,removed,wizardedit,20171114-00:18,310e73fc1d9
games-rpg/nwn-penultima,removed,wizardedit,20171114-00:18,310e73fc1d9
games-rpg/nwn-penultimarerolled,removed,wizardedit,20171114-00:18,310e73fc1d9
games-rpg/nwn-shadowlordsdreamcatcherdemon,removed,wizardedit,20171114-00:18,310e73fc1d9
games-rpg/nwn,removed,wizardedit,20171114-00:18,310e73fc1d9
Added Packages:
app-emacs/atomic-chrome,added,ulm,20171119-21:20,4461bf4001e
app-emacs

Re: [gentoo-dev] Re: No more stable keywords for Games

[Jules Octave]

can't affect me as I am not into games ; but I have tried some on kde ,
they seems to work fine.

2017-11-19 20:17 GMT+00:00 R0b0t1 :

> Hello friends!
>
> On Sun, Nov 19, 2017 at 12:45 PM, Philip Webb 
> wrote:
> > 171119 James Le Cuirot wrote:
> >> On Sun, 19 Nov 2017 08:50:20 -0500
> >> Philip Webb  wrote:
> >>> 171118 David Seifert wrote:
>  As the Games team does not have enough manpower to keep tabs on all
>  games packages, we have dropped all games-* ebuilds to unstable
>  keywords (modulo those required by stable non-games packages).
> >>> Isn't this overkill in the absence of widespread bug reports for games
> ?
> >>> 'Stable' doesn't mean well-maintained,
> >>> but in the tree for some time & no serious bug reports.
> >> There are plenty of bug reports for games.
> >
> > What percentage of games pkgs have bugs ?
>
> I too would like some clarification on the standards being used.
>
> > Marking all games 'unstable' still seems to be overkill.
> >
>
> To add to this, it is unlikely the situation will improve until it is
> made easier for people to contribute. If one is not aware there is a
> tendency for Gentoo-related issues to receive blog posts addressing
> them, or to be passed down via word of mouth on IRC, or to be hidden
> in a hard-to-find (and/or index) page of the Wiki.
>
> The most likely explanation for this state of affairs is that getting
> contributions accepted into the main tree is too hard.
>
> It is one thing to say that contributions to the main Portage tree
> require some standards to be upheld, but these standards do not seem
> to be applied consistently. For example, crossdev, genkernel, and the
> bootstrap-prefix and bootstrap-rap scripts are more or less
> unmaintainable disasters. Crossdev in particular oscillates between
> periods of relative stability and extreme brokenness, and the
> bootstrap scripts are poorly explained with no extant documentation
> and a workflow that does not clearly fit into Gentoo (or more properly
> Portage) development at large. Other ebuilds may simply install low
> quality software, or install software that is hard to manage with
> Portage.
>
> Respectfully,
>  R0b0t1
>
>

Re: [gentoo-dev] Re: No more stable keywords for Games

[R0b0t1]

Hello friends!

On Sun, Nov 19, 2017 at 12:45 PM, Philip Webb  wrote:
> 171119 James Le Cuirot wrote:
>> On Sun, 19 Nov 2017 08:50:20 -0500
>> Philip Webb  wrote:
>>> 171118 David Seifert wrote:
 As the Games team does not have enough manpower to keep tabs on all
 games packages, we have dropped all games-* ebuilds to unstable
 keywords (modulo those required by stable non-games packages).
>>> Isn't this overkill in the absence of widespread bug reports for games ?
>>> 'Stable' doesn't mean well-maintained,
>>> but in the tree for some time & no serious bug reports.
>> There are plenty of bug reports for games.
>
> What percentage of games pkgs have bugs ?

I too would like some clarification on the standards being used.

> Marking all games 'unstable' still seems to be overkill.
>

To add to this, it is unlikely the situation will improve until it is
made easier for people to contribute. If one is not aware there is a
tendency for Gentoo-related issues to receive blog posts addressing
them, or to be passed down via word of mouth on IRC, or to be hidden
in a hard-to-find (and/or index) page of the Wiki.

The most likely explanation for this state of affairs is that getting
contributions accepted into the main tree is too hard.

It is one thing to say that contributions to the main Portage tree
require some standards to be upheld, but these standards do not seem
to be applied consistently. For example, crossdev, genkernel, and the
bootstrap-prefix and bootstrap-rap scripts are more or less
unmaintainable disasters. Crossdev in particular oscillates between
periods of relative stability and extreme brokenness, and the
bootstrap scripts are poorly explained with no extant documentation
and a workflow that does not clearly fit into Gentoo (or more properly
Portage) development at large. Other ebuilds may simply install low
quality software, or install software that is hard to manage with
Portage.

Respectfully,
 R0b0t1

Re: [gentoo-dev] Re: cmake + ninja vs autotools

[Michael Orlitzky]

On 11/19/2017 01:00 PM, William L. Thomson Jr. wrote:
>>
>> This is broken: Static metadata like DEPEND must not depend
>> on dynamic data like environment variables which are supposed
>> to change at emerge time.
> 
> I wondered about that. I guess adding to DEPEND via eclass is bad then.
> 

So long as you add to DEPEND unconditionally, the issue that Martin
pointed out does not apply. If you need to fudge the conditional, you
can put it behind a USE flag; for example,

  DEPEND+=" some_use_expand_flag_foo? ( foo )"

in the eclass. That's still adding to DEPEND unconditionally, even
though its effect on the dependency tree (at "emerge" time) is
conditional on the USE flag.

Re: [gentoo-dev] Re: cmake + ninja vs autotools

[Georg Rudoy]

On 19.11.17 at 16:49 user Martin Vaeth  wrote:
>> Ninja is most of the speed of meson less configure time savings
> 
> ++
> For eix, the main motivation to support meson as an
> alternative build system was to be able to use ninja...

As somebody having a big C++/Qt/cmake project: there are basically two corner 
cases for the build scenario:

1. Doing a full clean build — that's what's relevant for Gentoo, and in this 
case the speed of make or ninja is hugely offset by the compilation speed, and 
their overhead is negligible.
2. Doing an incremental build after changing a couple of files — that's what 
relevant during normal development, and arguably not that relevant for Gentoo. 
And, ninja doesn't have that much of a speed advantage lately in this case. In 
fact, make turns out to be faster in the latter if the project is using automoc 
in cmake.

Just my two cents.


-- 
  Georg Rudoy

Re: [gentoo-dev] NEWS item for games destabling

[Rich Freeman]

On Sun, Nov 19, 2017 at 1:42 PM, Sergei Trofimovich  wrote:
> On Sun, 19 Nov 2017 15:46:02 +0100
> David Seifert  wrote:
>
>> games in Gentoo are not part of crucial Tier 1 packages.
>
> It's the first time I hear the term. How "crucial Tier 1 packages" are
> defined? Is there a link explaining/introducing the definition?
>

No.  IMO it is better to just drop that term.

Ultimately maintainers decide what gets stabilized, subject to the
general rule of 30 days in ~arch and no major bugs.  If the games team
is maintaining a package then they can decide not to have stable
keywords.

Note that not all games are necessarily maintained by the games team,
and this news item doesn't really make that clear.  Individual
maintainers are generally not bound to decisions made by the games
team, or at least that was the last council decision I recall on the
subject.

-- 
Rich

Re: [gentoo-dev] Re: No more stable keywords for Games

[Philip Webb]

171119 James Le Cuirot wrote:
> On Sun, 19 Nov 2017 08:50:20 -0500
> Philip Webb  wrote:
>> 171118 David Seifert wrote:
>>> As the Games team does not have enough manpower to keep tabs on all
>>> games packages, we have dropped all games-* ebuilds to unstable
>>> keywords (modulo those required by stable non-games packages).
>> Isn't this overkill in the absence of widespread bug reports for games ?
>> 'Stable' doesn't mean well-maintained,
>> but in the tree for some time & no serious bug reports.
> There are plenty of bug reports for games.

What percentage of games pkgs have bugs ?

Eg I amuse myself with  games-puzzle/sgt-puzzles ;
it is maintained upstream with regular updates.
The only unresolved bug appears to be 602696
which relates to version 20161207, which is no longer in the tree :
why is the bug still marked 'confirmed' ?  Shouldn't it be 'resolved' ?

What justification is there for marking this pkg 'unstable' ?
My guess is that there are other games pkgs with no valid bug.

Marking all games 'unstable' still seems to be overkill.

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] NEWS item for games destabling

[Sergei Trofimovich]

On Sun, 19 Nov 2017 15:46:02 +0100
David Seifert  wrote:

> NEWS item for de-stabled games
> 
> Title: No stable KEYWORDS for Gentoo Games
> Author: David Seifert 
> Content-Type: text/plain
> Posted: 2017-11-19
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Keyword: amd64 x86

Something very fancy going on with white-space here.

> As the Games team does not have enough manpower to keep tabs on all
> games packages, we have dropped all games-* ebuilds to unstable
> KEYWORDS (modulo those required by stable non-games packages).

Perhaps worth explicitly documenting new games@ keywording policy at
https://wiki.gentoo.org/wiki/Project:Games

> games in Gentoo are not part of crucial Tier 1 packages.

It's the first time I hear the term. How "crucial Tier 1 packages" are
defined? Is there a link explaining/introducing the definition?

-- 

  Sergei


pgpcvYRDg12fF.pgp
Description: Цифровая подпись OpenPGP

Re: [gentoo-dev] Re: cmake + ninja vs autotools

[William L. Thomson Jr.]

On Sun, 19 Nov 2017 16:49:51 + (UTC)
Martin Vaeth  wrote:

> William L. Thomson Jr.  wrote:
> >
> > case ${CMAKE_MAKEFILE_GENERATOR} in
> > emake)
> > DEPEND="sys-devel/make"
> > ;;
> > ninja)
> > DEPEND="dev-util/ninja"
> > ;;  
> 
> This is broken: Static metadata like DEPEND must not depend
> on dynamic data like environment variables which are supposed
> to change at emerge time.

I wondered about that. I guess adding to DEPEND via eclass is bad then.

> > Only 2 thus far does not sound like most things would have issues.  
> 
> In fact, almost nothing has issues.

That has been my experience why I brought it up.

>I am using
> CMAKE_MAKEFILE_GENERATOR=ninja in my make.conf
> since years, and the total list of packages which had
> ever failed here (out of currently ~1500 installed)
> is this:
> 
> dev-util/cmake
> kde-apps/kate
> kde-apps/gwenview
> media-libs/avidemux-core
> media-libs/avidemux-plugins
> media-video/avidemux
> media-video/kaffeine
> media-video/kmplayer
> net-vpn/kvpnc
> sci-mathematics/reduce
> 
> This list might appear long, but note that

That is not that long and seems to favor heavily in ninjas favor. Seems
considerably more have no issues with ninja than make.

Thanks for that information!
 
> > Ninja is most of the speed of meson less configure time savings  
> 
> ++
> For eix, the main motivation to support meson as an
> alternative build system was to be able to use ninja...

For new projects I do not want a deb or rpm I like meson +
ninja. For all other stuff I prefer cmake + ninja. Kinda best of both
worlds. At least till meson can spit out deb and rpm, not just rpm spec.

I also like how cmake updates po files. Not sure about pot file, meson
does have something there, and can update them. Just a separate
process. cmake updates po all the time, I like that :)

But either way meson or cmake, ninja is the main speed for compiling.
Though I do like the cmake make output formatting and color, etc.

-- 
William L. Thomson Jr.


pgpsyIoAkVBmh.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: cmake + ninja vs autotools

[Martin Vaeth]

William L. Thomson Jr.  wrote:
>
> case ${CMAKE_MAKEFILE_GENERATOR} in
> emake)
> DEPEND="sys-devel/make"
> ;;
> ninja)
> DEPEND="dev-util/ninja"
> ;;

This is broken: Static metadata like DEPEND must not depend
on dynamic data like environment variables which are supposed
to change at emerge time.

> Only 2 thus far does not sound like most things would have issues.

In fact, almost nothing has issues. I am using
CMAKE_MAKEFILE_GENERATOR=ninja in my make.conf
since years, and the total list of packages which had
ever failed here (out of currently ~1500 installed)
is this:

dev-util/cmake
kde-apps/kate
kde-apps/gwenview
media-libs/avidemux-core
media-libs/avidemux-plugins
media-video/avidemux
media-video/kaffeine
media-video/kmplayer
net-vpn/kvpnc
sci-mathematics/reduce

This list might appear long, but note that

1. */avidemux* is essentially only 1 package
2. net-vpn/kvpnc is ancient and masked
3. sci-mathematics/reduce is ancient and masked

and moreover, perhaps some other entries of this list are even
obsolete (I do not have installed KDE 5, so I cannot try quickly;
when I had added the packages to the list, KDE 4 was rather new...)

> Ninja is most of the speed of meson less configure time savings

++
For eix, the main motivation to support meson as an
alternative build system was to be able to use ninja...

[gentoo-dev] NEWS item for games destabling

[David Seifert]

NEWS item for de-stabled games

Title: No stable KEYWORDS for Gentoo Games
Author: David Seifert 
Content-Type: text/plain
Posted: 2017-11-19
Revision: 1
News-Item-Format: 1.0
Display-If-Keyword: amd64 x86

As the Games team does not have enough manpower to keep tabs on all
games packages, we have dropped all games-* ebuilds to unstable
KEYWORDS (modulo those required by stable non-games packages). If
you have any of these stable games packages installed, you will have
to add them to /etc/portage/package.accept_keywords/ manually.
Failures related to missing stable KEYWORDS will show up like

  The following keyword changes are necessary to proceed:
   (see "package.accept_keywords" in the portage(5) man page for
more details)
  # required by @selected
  # required by @world (argument)
  =games-action/0verkill-0.16-r4 ~amd64

While we accept that this will cause some irritation for the
community,
pretending we have a well supported games collection by having a
wealth
of stable games packages is misleading at best. By having 99% of
games
be unstable, we convey the expectation users should have - namely
that
games in Gentoo are not part of crucial Tier 1 packages.

We welcome contributions from outsiders willing to polish up the
games
landscape in Gentoo.

Re: [gentoo-dev] Re: No more stable keywords for Games

[James Le Cuirot]

On Sun, 19 Nov 2017 08:50:20 -0500
Philip Webb  wrote:

> 171118 David Seifert wrote:
> > As the Games team does not have enough manpower to keep tabs on all
> > games packages, we have dropped all games-* ebuilds to unstable
> > keywords (modulo those required by stable non-games packages).
> > 
> > While I accept that this will cause some irritation for the community,
> > pretending we have a well supported games collection by having a wealth
> > of stable games packages is misleading at best. By having 99% of games
> > be unstable, we convey the expectation users should have - namely that
> > games in Gentoo are not part of crucial Tier 1 packages.
> > 
> > We welcome contributions from outsiders willing to polish up the games
> > landscape in Gentoo.  
> 
> Isn't this overkill in the absence of widespread bug reports for games ?
> 'Stable' doesn't mean well-maintained,
> but in the tree for some time & no serious bug reports.

There are plenty of bug reports for games.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp51gAhMDnf5.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: No more stable keywords for Games

[Philip Webb]

171118 David Seifert wrote:
> As the Games team does not have enough manpower to keep tabs on all
> games packages, we have dropped all games-* ebuilds to unstable
> keywords (modulo those required by stable non-games packages).
> 
> While I accept that this will cause some irritation for the community,
> pretending we have a well supported games collection by having a wealth
> of stable games packages is misleading at best. By having 99% of games
> be unstable, we convey the expectation users should have - namely that
> games in Gentoo are not part of crucial Tier 1 packages.
> 
> We welcome contributions from outsiders willing to polish up the games
> landscape in Gentoo.

Isn't this overkill in the absence of widespread bug reports for games ?
'Stable' doesn't mean well-maintained,
but in the tree for some time & no serious bug reports.

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca