Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

2016-06-29 Thread Rich Freeman
On Wed, Jun 29, 2016 at 6:47 PM, Daniel Campbell  wrote:
> I'm glad to see some reach-out here and taking responsibility for
> decisions. However, what does the QA team have to say about systems that
> want games on other media (such as an SSD or separate HDD), or wish to
> restrict the use of games on their system to certain accounts?
>
> Bumping EAPI won't magically allow those to happen, and removing the
> eclass *will* break those use cases. What's the "blessed" way to do those?

Per-package install locations?  Sounds like a possible future EAPI
feature?  Of course, the real trick is when packages need to interact
and the files aren't in a fixed location.

In general right now I don't think we have a blessed way to install
stuff in non-standard locations.  Obviously you can fork an ebuild and
modify it, but if somebody wants to install KDE in /usr/kde/ and X11
into /usr/X11R6/ there isn't a clean way to do it.

-- 
Rich



Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

2016-06-29 Thread Daniel Campbell
On 06/29/2016 10:11 AM, Michał Górny wrote:
> Hello, everyone.
> 
> Over half a year has passed since Council decided upon the fate of
> games in Gentoo. Over that period, the games team has neither showed
> any will to respect the Council decisions, nor officially appealed to
> them.
> 
> For this reason, the QA team would like to officially start supporting
> the migration of ebuilds out of games.eclass. Any developer wishing to
> help is more than welcome to take any games.eclass ebuild, bump its
> revision and remove the games.eclass-specific bits from it. Updating to
> EAPI 6 would also be welcome. A short update guide is provided at
> the end of mail.
> 
> Please note that since this is considered a matter of QA action with
> a long waiting period, no explicit approval from games team is
> necessary to commit the conversion, nor games team is allowed to reject
> or revert such commits as long as they are valid.
> 
> If you need any help doing that and the games team refuses to provide
> it, please do not hesitate to contact me or ask in #gentoo-qa. If you
> are interested in helping out with games, feel free to join games team
> since it still lacks new members.
> 
> Thank you for all the help.
> 
> 
> Migration notes
> ---
> 
> TL;DR: nothing special required, remove games.eclass and all
> unnecessary games.eclass customization, and follow upstream. Make sure
> not to break stuff.
> 
> 
> The Council decisions can be summarized the following way:
> 
> 1. The 'games' group, formerly used to control access to games, must
> not be used. Games should be executable for all users like any other
> program [1].
> 
> 1a. For score files and similar writable shared data, the 'gamestat'
> group (enewgroup gamestat 36) can be used. The old 'games' group is not
> appropriate since sysadmins were expected to add users to it which
> defeated its purpose.
> 
> 2. Gentoo path customization for games must be removed and regular
> install locations (without explicit control via GAMES_* variables)
> should be used [2]:
> 
> 2a. /usr/games and /etc/games directories are forbidden,
> 
> 2b. /usr/share/games can be used for data if that directory is used
> upstream,
> 
> 2c. /var/games can be used for shared writable data.
> 
> 
> This is mostly achieved through removing games.eclass inherit,
> customization specific to it and replacing the helpers with generic PMS
> helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
> The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
> removed altogether.
> 
> In some cases it will also be beneficial to remove patching added to
> support non-standard locations.
> 
> Please remember to always rev-bump and not edit in place, to ensure
> proper upgrade. When dealing with dependencies, please make sure to
> check if the package does not rely on dependency installing data in
> a specific location. If that is the case, then you need to use
> appropriate >= deps to ensure clean upgrade.
> 
> If you would like to report bugs requesting games.eclass removal,
> please make them block the tracker [3].
> 
> 
> [1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
> [2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
> [3]:https://bugs.gentoo.org/show_bug.cgi?id=574082
> 
I'm glad to see some reach-out here and taking responsibility for
decisions. However, what does the QA team have to say about systems that
want games on other media (such as an SSD or separate HDD), or wish to
restrict the use of games on their system to certain accounts?

Bumping EAPI won't magically allow those to happen, and removing the
eclass *will* break those use cases. What's the "blessed" way to do those?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [warning] the bug queue has 82 bugs

2016-06-29 Thread Alex Alexander
Our bug queue has 82 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!



[gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

2016-06-29 Thread Michał Górny
Hello, everyone.

Over half a year has passed since Council decided upon the fate of
games in Gentoo. Over that period, the games team has neither showed
any will to respect the Council decisions, nor officially appealed to
them.

For this reason, the QA team would like to officially start supporting
the migration of ebuilds out of games.eclass. Any developer wishing to
help is more than welcome to take any games.eclass ebuild, bump its
revision and remove the games.eclass-specific bits from it. Updating to
EAPI 6 would also be welcome. A short update guide is provided at
the end of mail.

Please note that since this is considered a matter of QA action with
a long waiting period, no explicit approval from games team is
necessary to commit the conversion, nor games team is allowed to reject
or revert such commits as long as they are valid.

If you need any help doing that and the games team refuses to provide
it, please do not hesitate to contact me or ask in #gentoo-qa. If you
are interested in helping out with games, feel free to join games team
since it still lacks new members.

Thank you for all the help.


Migration notes
---

TL;DR: nothing special required, remove games.eclass and all
unnecessary games.eclass customization, and follow upstream. Make sure
not to break stuff.


The Council decisions can be summarized the following way:

1. The 'games' group, formerly used to control access to games, must
not be used. Games should be executable for all users like any other
program [1].

1a. For score files and similar writable shared data, the 'gamestat'
group (enewgroup gamestat 36) can be used. The old 'games' group is not
appropriate since sysadmins were expected to add users to it which
defeated its purpose.

2. Gentoo path customization for games must be removed and regular
install locations (without explicit control via GAMES_* variables)
should be used [2]:

2a. /usr/games and /etc/games directories are forbidden,

2b. /usr/share/games can be used for data if that directory is used
upstream,

2c. /var/games can be used for shared writable data.


This is mostly achieved through removing games.eclass inherit,
customization specific to it and replacing the helpers with generic PMS
helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
removed altogether.

In some cases it will also be beneficial to remove patching added to
support non-standard locations.

Please remember to always rev-bump and not edit in place, to ensure
proper upgrade. When dealing with dependencies, please make sure to
check if the package does not rely on dependency installing data in
a specific location. If that is the case, then you need to use
appropriate >= deps to ensure clean upgrade.

If you would like to report bugs requesting games.eclass removal,
please make them block the tracker [3].


[1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
[2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
[3]:https://bugs.gentoo.org/show_bug.cgi?id=574082

-- 
Best regards,
Michał Górny (on behalf of QA team)



pgpRKmomoXXMm.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: kde-apps/mplayerthumbs

2016-06-29 Thread Michael Palimaka
# Michael Palimaka  (29 Jun 2016)
# No longer released upstream. Use kde-apps/ffmpegthumbs instead.
# Masked for removal in 30 days.
kde-apps/mplayerthumbs



Re: [gentoo-dev] Re: Infiniband/OmniPath/iWARP and other RDMA related staff

2016-06-29 Thread Alexey Shvetsov
В письме от среда, 29 июня 2016 г. 13:19:06 MSK пользователь Holger Hoffstätte 
написал:
> On Wed, 29 Jun 2016 10:07:07 +0300, Alexey Shvetsov wrote:
> > Hi all!
> > 
> > I'm going to revive RDMA fabric related things in gentoo. And since its
> > not
> 
> Yay!
> 
> > only about infiniband staff but about more generic fabric types there is
> > and idea to rename category sys-infiniband to more generic name.
> > Suggestions are
> > 
> > sys-rdma
> > sys-fabric
> > 
> > What will be inside? It will be RDMA related stuff like OFED, fabric
> > userspace drivers (verbs, psm, psm2, libfabric and others), plugins for
> > specific devices, tools to flash RDMA cards and other related staff.
> 
> This makes me happy. I've been playing with a standalone libfabric in my
> overlay via the sockets/UDP providers, and had nothing but problems when I
> tried to add USE flags for the various OFED bits (psm2 etc.)

Thats is the part of plan =)

> 
> An up-to-date libfabric that pulls in ofed only when needed would finally
> enable people without the otherwise necessary fabric HW to write against
> the much more usable & sane (when compared to raw IB verbs) libfabric APIs.
> 
> As far as the name is concerned IMHO fabric sounds less RDMA-specific;
> I think the OFI WG now also prefers implementation-neutral terms.

In current state i also preffer to rename it to 

sys-fabric 

and put all interconnect related stuff here (yes sys-cluster/knem  and sys-
cluster/open-mx also should go here)

So if there will be no objections i will do move in next 2 days

> 
> cheers,
> Holger


-- 
Best Regards,
Alexey 'Alexxy' Shvetsov, PhD
Department of Molecular and Radiation Biophysics
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Leningrad region, Gatchina, Russia
mailto:alexx...@gmail.com
mailto:ale...@omrb.pnpi.spb.ru
mailto:ale...@gentoo.org

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: Infiniband/OmniPath/iWARP and other RDMA related staff

2016-06-29 Thread Holger Hoffstätte
On Wed, 29 Jun 2016 10:07:07 +0300, Alexey Shvetsov wrote:

> Hi all!
> 
> I'm going to revive RDMA fabric related things in gentoo. And since its not 

Yay!

> only about infiniband staff but about more generic fabric types there is and 
> idea to rename category sys-infiniband to more generic name. Suggestions are
> 
> sys-rdma
> sys-fabric
> 
> What will be inside? It will be RDMA related stuff like OFED, fabric 
> userspace 
> drivers (verbs, psm, psm2, libfabric and others), plugins for specific 
> devices, 
> tools to flash RDMA cards and other related staff.

This makes me happy. I've been playing with a standalone libfabric in my
overlay via the sockets/UDP providers, and had nothing but problems when I
tried to add USE flags for the various OFED bits (psm2 etc.)

An up-to-date libfabric that pulls in ofed only when needed would finally enable
people without the otherwise necessary fabric HW to write against the much more
usable & sane (when compared to raw IB verbs) libfabric APIs.

As far as the name is concerned IMHO fabric sounds less RDMA-specific;
I think the OFI WG now also prefers implementation-neutral terms.

cheers,
Holger




Re: [gentoo-dev] Infiniband/OmniPath/iWARP and other RDMA related staff

2016-06-29 Thread Aaron Bauman

On Wednesday, June 29, 2016 4:07:07 PM JST, Alexey Shvetsov wrote:

Hi all!

I'm going to revive RDMA fabric related things in gentoo. And since its not 
only about infiniband staff but about more generic fabric types 
there is and 
idea to rename category sys-infiniband to more generic name. Suggestions are




That would be wonderful, especially with the longstanding security issues 
against sys-infiniband/*.  Bugs 438444, 438446, 463338.


I hope your project goes well.  :)


sys-rdma
sys-fabric

What will be inside? It will be RDMA related stuff like OFED, 
fabric userspace 
drivers (verbs, psm, psm2, libfabric and others), plugins for 
specific devices, 
tools to flash RDMA cards and other related staff.







Re: [gentoo-dev] Infiniband/OmniPath/iWARP and other RDMA related staff

2016-06-29 Thread Andrew Savchenko
On Wed, 29 Jun 2016 10:07:07 +0300 Alexey Shvetsov wrote:
> Hi all!
> 
> I'm going to revive RDMA fabric related things in gentoo. And since its not 
> only about infiniband staff but about more generic fabric types there is and 
> idea to rename category sys-infiniband to more generic name. Suggestions are
> 
> sys-rdma
> sys-fabric
> 
> What will be inside? It will be RDMA related stuff like OFED, fabric 
> userspace 
> drivers (verbs, psm, psm2, libfabric and others), plugins for specific 
> devices, 
> tools to flash RDMA cards and other related staff.

If sys-fabric name will be used, stuff like sys-cluster/knem
should go there too, imho. Probably this is not what intended, so
sys-rdma seems to be better name.

Best regards,
Andrew Savchenko


pgpTgutmZuPxt.pgp
Description: PGP signature


[gentoo-dev] Infiniband/OmniPath/iWARP and other RDMA related staff

2016-06-29 Thread Alexey Shvetsov
Hi all!

I'm going to revive RDMA fabric related things in gentoo. And since its not 
only about infiniband staff but about more generic fabric types there is and 
idea to rename category sys-infiniband to more generic name. Suggestions are

sys-rdma
sys-fabric

What will be inside? It will be RDMA related stuff like OFED, fabric userspace 
drivers (verbs, psm, psm2, libfabric and others), plugins for specific devices, 
tools to flash RDMA cards and other related staff.

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov, PhD
Department of Molecular and Radiation Biophysics
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Leningrad region, Gatchina, Russia
mailto:alexx...@gmail.com
mailto:ale...@omrb.pnpi.spb.ru
mailto:ale...@gentoo.org

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] RFC: extension to prefix.eclass

2016-06-29 Thread Benda Xu
Hi anonymous reviewer,

R0b0t1  writes:

> What is it intended to solve?

To simplify ebuilds that need to call eprefixify.

> The current behavior seems to make more sense. Hiding defaults causes
> problems. 

I am not sure what you mean by "Hiding defaults". It is documented, not
hidden.

The regular expression
  
  "s,([^[:alnum:]}])/(usr|etc|bin|sbin|var|opt)/,\1${EPREFIX}/\2/,g"

is conesrvative.  And it will be scrutinized by the community.

Most files can be trivially prefixified by this regular expression.

Traditionally, we need generate a patch with @GENTOO_PORTAGE_EPREFIX@,
apply the patch and then eprefixify the source (which was
"s|@GENTOO_PORTAGE_EPREFIX@|${EPREFIX}|g").  We need a lot of such
trivial patches and it is not version-bump-proof.

Having a sane default improves maintainability.  That's the point of
ebuild helpers and eclasses.

> `fprefixify` is redundant.

No, it's not redundant.  An example of fprefixify is attached.

Benda

--- a/app-shells/bash/bash-4.3_p42-r2.ebuild
+++ b/app-shells/bash/bash-4.3_p42-r2.ebuild
@@ -88,11 +88,7 @@ src_prepare() {
 	epatch "${FILESDIR}"/${PN}-4.3-mapfile-improper-array-name-validation.patch
 	epatch "${FILESDIR}"/${PN}-4.3-arrayfunc.patch
 
-	epatch "${FILESDIR}"/${PN}-4.0-configs-prefix.patch
-	eprefixify pathnames.h.in
-	# modify the bashrc file for prefix
-	cp "${FILESDIR}"/bashrc "${T}"/ || die
-	eprefixify "${T}"/bashrc
+	fprefixify epatch "${FILESDIR}"/${PN}-4.0-configs-prefix.patch
 
 	epatch_user
 }
@@ -183,7 +179,7 @@ src_install() {
 
 	insinto /etc/bash
 	doins "${FILESDIR}"/bash_logout
-	doins "${T}"/bashrc
+	fprefixify doins "${FILESDIR}"/bashrc
 	keepdir /etc/bash/bashrc.d
 	insinto /etc/skel
 	for f in bash{_logout,_profile,rc} ; do