Re: [gentoo-dev] pkgdev commit and gpg-agent

2022-08-01 Thread Andrew Savchenko
On Mon, 1 Aug 2022 15:49:18 + (UTC) Andrey Grozin wrote:
> Hello *,
> 
> Sorry for a very naive question.
> 
> In the past, I used
> repoman commit
> to commit a new ebuild. I got a text screen in my terminal where I typed my
> passphraise (if I then committed something else within the timeout, I didn't
> have to re-type it).
> 
> Now we are recommended to use
> pkgdev commit
> instead. But it does not ask for my passphraise, just writes an error message
> that it cannot sign my commit.
> 
> If I commit something with repoman and then (within the timeout) commit
> something else with pkgdev, it works.
> 
> My .gnupg/gpg-agent.conf is
> 
> pinentry-program /usr/bin/pinentry-curses
> write-env-file
> default-cache-ttl 100
> 
> My .gnupg/gpg.conf includes the line
> 
> use-agent
> 
> I can, of course, continue to use repoman for committing. But now it does not
> add the Signed-off-by: automatically. I have to add it by hand, in nano. This 
> is
> definitely the most convenient way.

I have the same problem with pkgdev. It fails to run at
least CLI/TUI pinentry when password is needed. To workaround
I sign some dummy file with `gpg -s file`, then within cache period
I can use it for commits using pkgdev.

Cache timeout can be set in gpg-agent.conf, e.g. in seconds:
default-cache-ttl 7200

Furthermore I can't use `pkgdev push` to push my commits, because
it fails to sign the push and the server rejects my push. I have no
idea why, because `git push --signed' works perfectly fine.
Regarding pushing to git (I mean git push process, not various
checks), pkgdev should do the same as `git push --signed`, but it
apparently does not.

And last but not the least pkgdev have some problem I could not
precisely identify that makes gpg socket forwarding unusable, so I
can't forward nitrokey from another host. Plain gpg usually works.

Best regards,
Andrew Savchenko


pgpG08RetJogI.pgp
Description: PGP signature


Re: [gentoo-dev] Printer drivers and net-print

2021-12-17 Thread Andrew Savchenko
On Fri, 17 Dec 2021 14:00:48 +0100 Andreas Sturmlechner wrote:
> On Montag, 20. Februar 2017 22:47:17 CET Andreas K. Huettel wrote:
> > Hey all,
> > 
> > 1) Putting printer drivers into "net-print" is silly.
> > 
> > Something that converts format a to device-specific format b has absolutely
> > nothing to do with network.
> > So, a new category "sys-print", emphasizing that it's hardware drivers, (or
> > "cups-drv"?) (or maybe "media-print"?) might make sense.
> > 
> > 2) After introducing that, however, "net-print" becomes nearly empty.
> > 
> > On a quick glance, the only *network*-specific packages in there are cups
> > and lprng. Maybe one or two more which I dont recognize.
> > 
> > So move cups and lprng to "net-misc" and drop "net-print"?
> > Or move them to new "sys-print" as well?
> > 
> > What do you think?
> > 
> > Cheers,
> > Andreas
> 
> I would like to resume this discussion on the occasion of a new [shameless 
> plug] package PAPPL that is to be packaged, see also [1], from the point 
> before discussion went off on an X-Y categories tangent.
> 
> Here's a list of suggestions made for a new category so far, ordered from 
> (seemingly) best- to least-liked:
> 
> media-print
> sys-print
> app-print(ing)

IMHO sys-print is the best variant, since printing often requires
system privileges to set it up or change lots of settings.

Best regards,
Andrew Savchenko


pgpCQ1b4x5Cci.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] kernel-2.eclass: Respect portage CC & AR variables

2021-12-15 Thread Andrew Savchenko
On Thu, 16 Dec 2021 03:32:10 +0300 Andrew Savchenko wrote:
> On Wed, 15 Dec 2021 16:58:26 +0200 Adrian Ratiu wrote:
> > Starting with kernel>=v5.7 the build system can override the
> > tools vars by setting LLVM=1 [1], but older kernels still use
> > the default GNU tools, so to be able to use a full LLVM/Clang
> > build, CC should be set together with AR to the portage set
> > values.
> > 
> > Doing this avoids situations like building the kernel with
> > clang (using the set HOSTCC) but using gcc/gnu-ar for headers.
> > 
> > [1] a0d1c951ef08 kbuild: support LLVM=1 to switch the default tools to 
> > Clang/LLVM
> > 
> > Co-authored-by: Manoj Gupta 
> > Signed-off-by: Adrian Ratiu 
> > ---
> >  eclass/kernel-2.eclass | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> > index adc1425bc2e..caeec86ff59 100644
> > --- a/eclass/kernel-2.eclass
> > +++ b/eclass/kernel-2.eclass
> > @@ -692,7 +692,7 @@ env_setup_xmakeopts() {
> > elif type -p ${CHOST}-ar >/dev/null; then
> > xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
> > fi
> > -   xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
> > +   xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC) 
> > AR=$(tc-getAR)"
> 
> OBJDUMP should be exported as well
> (e.g. used by scripts/Makefile.build)

And LD as well.
 
> > export xmakeopts
> >  }
> >  
> 
> 
> Best regards,
> Andrew Savchenko


Best regards,
Andrew Savchenko


pgpBxIoLQ06uf.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] kernel-2.eclass: Respect portage CC & AR variables

2021-12-15 Thread Andrew Savchenko
On Wed, 15 Dec 2021 16:58:26 +0200 Adrian Ratiu wrote:
> Starting with kernel>=v5.7 the build system can override the
> tools vars by setting LLVM=1 [1], but older kernels still use
> the default GNU tools, so to be able to use a full LLVM/Clang
> build, CC should be set together with AR to the portage set
> values.
> 
> Doing this avoids situations like building the kernel with
> clang (using the set HOSTCC) but using gcc/gnu-ar for headers.
> 
> [1] a0d1c951ef08 kbuild: support LLVM=1 to switch the default tools to 
> Clang/LLVM
> 
> Co-authored-by: Manoj Gupta 
> Signed-off-by: Adrian Ratiu 
> ---
>  eclass/kernel-2.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index adc1425bc2e..caeec86ff59 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -692,7 +692,7 @@ env_setup_xmakeopts() {
>   elif type -p ${CHOST}-ar >/dev/null; then
>   xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
>   fi
> - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
> + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC) 
> AR=$(tc-getAR)"

OBJDUMP should be exported as well
(e.g. used by scripts/Makefile.build)

>   export xmakeopts
>  }
>  


Best regards,
Andrew Savchenko


pgpodFBDDef4_.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites: net-dns/pdnsd

2021-12-13 Thread Andrew Savchenko
On Mon, 13 Dec 2021 09:34:46 +0100 Lars Wendler wrote:
> On Sun, 12 Dec 2021 13:35:20 +0300 Andrew Savchenko wrote:
> 
> >On Tue, 7 Dec 2021 15:33:34 +0100 Lars Wendler wrote:
> >> Fails to build with recent kernel headers (bug #801688).
> >> Upstream is gone for a long time. Masked for removal in 30 days.
> >> Users should switch over to net-dns/dnsmasq which provides similar
> >> features.
> >
> >Depending on usage profile net-dns/unbound may be a better
> >replacement. For me a killer feature of pdnsd was the persistent
> >dns cache, which is very useful on mobile devices. Dnsmasq doesn't
> >have one, but unbound now has.
> >
> >Best regards,
> >Andrew Savchenko
> 
> Feel free to extend the mask message.
> Although I'm considering to cancel the last rite now that a patch has
> been submitted to bug #801688.

Yes, keeping package would be the best option since patch is
available: it has many diverse uses.

Best regards,
Andrew Savchenko


pgpAKN8h6AU7K.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites: net-dns/pdnsd

2021-12-12 Thread Andrew Savchenko
On Tue, 7 Dec 2021 15:33:34 +0100 Lars Wendler wrote:
> Fails to build with recent kernel headers (bug #801688).
> Upstream is gone for a long time. Masked for removal in 30 days.
> Users should switch over to net-dns/dnsmasq which provides similar
> features.

Depending on usage profile net-dns/unbound may be a better
replacement. For me a killer feature of pdnsd was the persistent
dns cache, which is very useful on mobile devices. Dnsmasq doesn't
have one, but unbound now has.

Best regards,
Andrew Savchenko


pgp3INGYXBpaV.pgp
Description: PGP signature


[gentoo-dev] Last rites: app-doc/clsync-docs dev-libs/libclsync

2020-12-26 Thread Andrew Savchenko
# Andrew Savchenko  (2020-12-26)
# All docs and socket library functionality are merged back into single
# app-admin/clsync package using USE="apidoc doc socket-library" starting
# from clsync-0.4.5.
# No reverse dependencies. Removal in 30 days.


pgpJZDAZGWp60.pgp
Description: PGP signature


Re: [gentoo-dev] Python 2 cleanup: remaining packages, Dec 2020 update

2020-12-05 Thread Andrew Savchenko
On Sat, 05 Dec 2020 15:47:40 + Marek Szuba wrote:
> 
> 
> On December 5, 2020 12:31:33 PM UTC, Andrew Savchenko  
> wrote:
> 
> >Looks like you misunderstood what "Python 3 compatibility mode"
> >means. See official explanation:
> >https://www.renpy.org/dev-doc/html/changelog.html#python-2-python-3-compatibility-mode
> 
> So I have. Oh well, last rites it most likely is then.  Or move
> py2 versions of RenPy and their revdeps to a dedicated overlay,
> maybe.

Do we have a dedicated py2 overlay? Renpy has quite some py2 deps,
so it will be reasonable to support it in such overlay instead of
duplicating job for common packages.

> I am not quite convinced simply having then masked in the
> main tree makes sense, as these will have to stay masked even after
> RenPy 8.0 has come out.

The sense I see:
1) it will make it easier to update to 8.0;
2) for users willing to use renpy it will be a starting point,
though they'll need to setup py2 outside of portage somehow, maybe
using pip.

But maybe it will be easier for users to use bundled renpy from
games (it often comes with its own py2); though not all games have
linux port — that is the killer feature of the in-tree renpy
version.

Best regards,
Andrew Savchenko


pgp8XYKwjv62Y.pgp
Description: PGP signature


Re: [gentoo-dev] Python 2 cleanup: remaining packages, Dec 2020 update

2020-12-05 Thread Andrew Savchenko
Hi!

On Fri, 4 Dec 2020 10:07:21 +0100 Marek Szuba wrote:
> On 2020-12-04 01:54, Michał Górny wrote:
> 
> >>> Waiting for py3 port (likely last rite candidates):
> >>> - games-engines/renpy
> >>
> >> RenPy 7.4.0, released on the 26th of November, features "new Python 3
> >> compatibility mode". It is of course up to the maintainer of this
> >> package to decide how to proceed but were this up to me, I would very
> >> much rather version-bump games-engines/renpy (in spite of 7.4.0 being
> >> described by upstream as a pre-release) than last-rite it altogether.

Looks like you misunderstood what "Python 3 compatibility mode"
means. See official explanation:
https://www.renpy.org/dev-doc/html/changelog.html#python-2-python-3-compatibility-mode
*
Full Changelog
7.4.0
[...]
Python 2/Python 3 Compatibility Mode

While Ren'Py is not yet supported on Python 3, this release of
Ren'Py includes several features to allow you to begin writing
scripts that will work on both Python 2 and Python 3.
*

Just to be sure I tried to build renpy-7.4.0 using python3: it
fails because it still uses python2 code inside (but with import
future, so it can support scripts in python 3).

Python3 support for the RenPy itself is expected in 8.0 version.

> > Sure but I'm afraid the games will need explicit porting to py3 as well.
> 
> Well, the games will probably have to go - if I see correctly we have 
> currently got 4 games-engines/renpy revdeps in the tree 
> (games-misc/katawa-shoujo, games-rpg/asphyxia, games-rpg/sakura-spirit, 
> games-rpg/the-royal-trap) and they all explicitly depend on a slotted 
> older version of the engine.

1. pygame_sdl2 is ported to python3, so there is no need to remove
it even if renpy will be temporarily gone.

2. It should be possible to keep renpy and games as masked in the
tree, but this will require users to setup some python2 env
themselves. If this is an acceptable option, I can bump renpy to
7.4.0 in the tree.

Best regards,
Andrew Savchenko


pgpLur_fqtS57.pgp
Description: PGP signature


[gentoo-dev] Last rites: net-fs/openafs-kernel

2020-10-11 Thread Andrew Savchenko
# Andrew Savchenko  (2020-10-11)
# Mask old openafs version and corresponding openafs-kernel with
# multiple CVEs.
# All kernel module functionality is merged back in the single
# net-fs/openafs package using USE="modules" starting from 1.8 branch.
# No reverse dependencies, bug #719136. Removal in 30 days.
net-fs/openafs-kernel


pgpmKnlQLLfii.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files

2020-09-13 Thread Andrew Savchenko
On Sat, 29 Aug 2020 21:53:45 +0200 Michał Górny wrote:
> Thanks to David Michael for the initial patch and upstream fixes.
> 
> Signed-off-by: Michał Górny 
> ---
>  eclass/acct-group.eclass | 16 +++-
>  eclass/acct-user.eclass  | 16 +++-
>  2 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> index 5550e4a2fb10..dc1562974870 100644
> --- a/eclass/acct-group.eclass
> +++ b/eclass/acct-group.eclass
> @@ -80,7 +80,7 @@ S=${WORKDIR}
>  
>  
>  # << Phase functions >>
> -EXPORT_FUNCTIONS pkg_pretend pkg_preinst
> +EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst
>  
>  # @FUNCTION: acct-group_pkg_pretend
>  # @DESCRIPTION:
> @@ -116,6 +116,20 @@ acct-group_pkg_pretend() {
>   fi
>  }
>  
> +# @FUNCTION: acct-group_src_install
> +# @DESCRIPTION:
> +# Installs sysusers.d file for the group.
> +acct-group_src_install() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + insinto /usr/lib/sysusers.d
> + newins - ${CATEGORY}-${ACCT_GROUP_NAME}.conf < <(
> + printf "g\t%q\t%q\n" \
> + "${ACCT_GROUP_NAME}" \
> + "${ACCT_GROUP_ID/#-*/-}"
> + )
> +}
> +
>  # @FUNCTION: acct-group_pkg_preinst
>  # @DESCRIPTION:
>  # Creates the group if it does not exist yet.
> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> index e82f3c56dbbe..f9772c3cb111 100644
> --- a/eclass/acct-user.eclass
> +++ b/eclass/acct-user.eclass
> @@ -312,7 +312,7 @@ acct-user_pkg_pretend() {
>  # @FUNCTION: acct-user_src_install
>  # @DESCRIPTION:
>  # Installs a keep-file into the user's home directory to ensure it is
> -# owned by the package.
> +# owned by the package, and sysusers.d file.
>  acct-user_src_install() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> @@ -321,6 +321,20 @@ acct-user_src_install() {
>   # created yet
>   keepdir "${ACCT_USER_HOME}"
>   fi
> +
> + insinto /usr/lib/sysusers.d
> + newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <(
> + printf "u\t%q\t%q\t%q\t%q\t%q\n" \
> + "${ACCT_USER_NAME}" \
> + "${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \
> + "${DESCRIPTION//[:,=]/;}" \
> + "${ACCT_USER_HOME}" \
> + "${ACCT_USER_SHELL/#-*/-}"
> + if [[ ${#ACCT_USER_GROUPS[@]} -gt 1 ]]; then
> + printf "m\t${ACCT_USER_NAME}\t%q\n" \
> + "${ACCT_USER_GROUPS[@]:1}"
> + fi
> + )
>  }

Why these files are installed unconditionally?

Of course we have a common "small files" policy that USE flags
should not control small files in packages, such rule was designed
for common packages where:
  1) small files are insignificant disk usage compared to a whole
package;
  2) an average package takes significant time to rebuild and mass
rebuild will cause problems during USE flip.

While both arguments are valid for a common packages which provide
real software, this is not true for very special acct-* packages:
  1) They may (and usually do) have zero size of installed files,
this makes sysusers.d stuff an infinite times larger than a
whole typical acct-* package (it will still be much larger if one
will consider size of new passw/group records).
  2) acct-* packages are very fast to rebuild, so such price will
be small compared to other changes necessary when USE="systemd" is
being flipped.

So it will be reasonable to add USE="systemd" to acct-* eclasses
to control the changes proposed above.

Best regards,
Andrew Savchenko


pgps8XkbFsi5J.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-20 Thread Andrew Savchenko
On Sun, 21 Jul 2019 00:33:00 +0200 Michał Górny wrote:
> On Sat, 2019-07-20 at 18:16 -0400, Rich Freeman wrote:
> > On Sat, Jul 20, 2019 at 4:22 PM Michał Górny  wrote:
> > > 
> > > Yes, I get it.  User experience is not important if it would mean
> > > developers would actually do anything but the bare minimum to get
> > > from one paycheck to another.  The usual Gentoo attitude.
> > > 
> > 
> > Not sure where I go to sign up for those paychecks.  However, even
> > employers have to accept that policies have a resource cost to them.
> > 
> > Requiring people to do more than the bare minimum often just ensures
> > that they won't even bother to do the bare minimum.  I'm all for
> > finding ways to standardize things so that everybody benefits at a
> > very low cost.  This doesn't seem that, and honestly requiring
> > packages to bundle pre-built manpages seems a bit non-Gentooish to
> > begin with.
> > 
> 
> Then you should go and strip all those pregenerated autotools files,
> and require eautoreconf from every single package.

This might be a good idea, actually. Version mismatch between
shipped pregenerated files and system autotools occasionally causes
some problems.

Best regards,
Andrew Savchenko


pgpcJaILmwY2y.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-20 Thread Andrew Savchenko
On Sat, 20 Jul 2019 20:28:39 +0200 Michał Górny wrote:
> On Sat, 2019-07-20 at 20:50 +0300, Andrew Savchenko wrote:
> > On Wed, 17 Jul 2019 15:25:10 +0200 Michał Górny wrote:
> > > Hello,
> > > 
> > > The QA team would like to introduce the following policy:
> > > 
> > > """
> > > Packages must not disable installing manpages via USE flags (e.g.
> > > USE=man or USE=doc).  If upstream does not ship prebuilt manpages
> > > and building them requires additional dependencies, the maintainer
> > > should build them and ship along with the package.
> > > """
> > > 
> > > 
> > > Explanatory note:
> > > 
> > > This applies to having USE flags that specifically control building
> > > manpages.  It obviously does not affect:
> > > 
> > > a. USE flags that disable building both a program and its manpage (e.g.
> > > if USE=gui disables building gfrobnicate, not installing gfrobnicate(1)
> > > is correct),
> > > 
> > > b. use of LINGUAS to control installed manpages.
> > > 
> > > 
> > > Rationale:
> > > 
> > > Manpages are the basic form of user documentation on Gentoo Linux.  Not
> > > installing them is harmful to our users.  On the other hand, requiring
> > > additional dependencies is inconvenient.  Therefore, packaging prebuilt
> > > manpages (whenever upstream doesn't do that already) is a good
> > > compromise that provides user with documentation without additional
> > > dependencies.
> > > 
> > > 
> > > What are your comments?
> > 
> > The basic foundation of Gentoo is freedom of choise for our users.
> > If installing man pages means no additional dependencies, than
> > proposed rule is ok. However if such dependencies are required it is
> > up to users to decide if they wan them or not.
> > 
> > Having USE=man (or USE=doc) for such purposes is fine. Having
> > USE=man enabled by default in user profile is also fine. Forcing
> > users to install unnecessary dependencies on minimal systems in a
> > no go and turns Gentoo into something else.
> > 
> 
> Could you please read the proposed policy?  It explicitly says you are
> *not* supposed to force extra deps on users but build manpages for them.

Could you please what the other developers have already replied to
you on this matter? This will be a significant increase in
maintenance burden for both developers and advanced users without
much to gain.

Best regards,
Andrew Savchenko


pgpAo_KyxAOs3.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-20 Thread Andrew Savchenko
On Wed, 17 Jul 2019 15:25:10 +0200 Michał Górny wrote:
> Hello,
> 
> The QA team would like to introduce the following policy:
> 
> """
> Packages must not disable installing manpages via USE flags (e.g.
> USE=man or USE=doc).  If upstream does not ship prebuilt manpages
> and building them requires additional dependencies, the maintainer
> should build them and ship along with the package.
> """
> 
> 
> Explanatory note:
> 
> This applies to having USE flags that specifically control building
> manpages.  It obviously does not affect:
> 
> a. USE flags that disable building both a program and its manpage (e.g.
> if USE=gui disables building gfrobnicate, not installing gfrobnicate(1)
> is correct),
> 
> b. use of LINGUAS to control installed manpages.
> 
> 
> Rationale:
> 
> Manpages are the basic form of user documentation on Gentoo Linux.  Not
> installing them is harmful to our users.  On the other hand, requiring
> additional dependencies is inconvenient.  Therefore, packaging prebuilt
> manpages (whenever upstream doesn't do that already) is a good
> compromise that provides user with documentation without additional
> dependencies.
> 
> 
> What are your comments?

The basic foundation of Gentoo is freedom of choise for our users.
If installing man pages means no additional dependencies, than
proposed rule is ok. However if such dependencies are required it is
up to users to decide if they wan them or not.

Having USE=man (or USE=doc) for such purposes is fine. Having
USE=man enabled by default in user profile is also fine. Forcing
users to install unnecessary dependencies on minimal systems in a
no go and turns Gentoo into something else.

Best regards,
Andrew Savchenko


pgpCavgJUlohO.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-21 Thread Andrew Savchenko
On Fri, 21 Jun 2019 09:18:23 +0200 David Seifert wrote:
> On Fri, 2019-06-21 at 08:59 +0300, Andrew Savchenko wrote:
> > On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote:
> > > On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote:
> > > > On 6/9/2019 7:39 AM, Michał Górny wrote:
> > > > > +Tracking of user/group usage is done through dependencies.  As
> > > > > long
> > > > > +as any installed package depends on a specific user/group
> > > > > package,
> > > > > +the respective user/group is assumed to be used.  If no
> > > > > package
> > > > > +requiring the specific user/group is left, the package manager
> > > > > +automatically prunes the package clearly indicating it is no
> > > > > longer
> > > > > +used.
> > > > 
> > > > You cannot know when a name is "no longer used".  An
> > > > administrator could
> > > > have adopted a username for other purposes.
> > > 
> > > That's why we don't remove the actual user/group.  However, this is
> > > a valuable information to the administrator that no package is
> > > using
> > > the user/group in question.
> > 
> > So how do you propose to clean them up? Or let user systems trash
> > with unused uids/gids? The GLEP 81 only mensions some possible
> > tooling for cleanup. Is there an implementation available? I don't
> > see it within proposed patch sets.
> > 
> > This GLEP should not be accepted unless all necessary tools are
> > available including a cleanup tool.
> > 
> > Best regards,
> > Andrew Savchenko
> 
> Strongly disagree:
> 
> 1) User systems are already getting trashed. And apparently it's not a
> critical thing that prevents users from using Gentoo in practice.
> 2) A cleanup tool at best will only tell you which files you need to
> check, randomly deleting files with orphaned uids/gids is not a good
> idea.

What will happen when some acct-*/* package will be unmerged? Will
uid/gid record and/or its files be deteleted?

> 3) This proposal strictly increases the quality of Gentoo. Don't let
> perfect be the enemy of the good. The fact that the problem isn't
> solved to 100% doesn't mean that a solution that gets us there 85%
> should be rejected.
> 
> Strongly vote +1 to merge this now.
> 
> 


Best regards,
Andrew Savchenko


pgpDwJ3IynjJd.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-21 Thread Andrew Savchenko
Hi!

On Thu, 20 Jun 2019 09:53:46 -0400 Brian Evans wrote:
> > +
> > +Before adding a new user and/or group, the developer must send a RFC
> > +to the ``gentoo-dev`` mailing list.
> 
> This paragraph should go away.  It is a complete waste of time.

> > +Requiring mailing list RFC
> > +--
> > +
> > +The policy explicitly requires RFC-es for new users and groups, as they
> > +have global scopes and effects of mistakes while adding them are hard
> > +to fix.  Wider review should decrease the risk of major design mistakes.
> > +
> > +To provide one example, right now we have two different packages
> > +creating ``git`` user and requiring a different home directory for
> > +the user.  As a result, the first package being installed defines
> > +the actual home directory, and both technically can not be installed
> > +at the same time.
> 
> This section should go away.  It is a complete waste of time.

Mail list discussion may make sense only if users or groups and
intended to be shared between different applications (e.g. ftp,
mail, ntp). If user or group are intended to be application
specific, there is no need for such discussions as they will just
hinder development process.

Best regards,
Andrew Savchenko


pgp1O4TymKEO2.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-21 Thread Andrew Savchenko
On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote:
> On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote:
> > On 6/9/2019 7:39 AM, Michał Górny wrote:
> > > +Tracking of user/group usage is done through dependencies.  As long
> > > +as any installed package depends on a specific user/group package,
> > > +the respective user/group is assumed to be used.  If no package
> > > +requiring the specific user/group is left, the package manager
> > > +automatically prunes the package clearly indicating it is no longer
> > > +used.
> > 
> > You cannot know when a name is "no longer used".  An administrator could
> > have adopted a username for other purposes.
> 
> That's why we don't remove the actual user/group.  However, this is
> a valuable information to the administrator that no package is using
> the user/group in question.

So how do you propose to clean them up? Or let user systems trash
with unused uids/gids? The GLEP 81 only mensions some possible
tooling for cleanup. Is there an implementation available? I don't
see it within proposed patch sets.

This GLEP should not be accepted unless all necessary tools are
available including a cleanup tool.

Best regards,
Andrew Savchenko


pgpDkqP5Gug7l.pgp
Description: PGP signature


Re: [gentoo-dev] last rites: app-accessibility/festival and reverse dependencies

2019-06-09 Thread Andrew Savchenko
On Wed, 5 Jun 2019 01:21:29 +0300 Andrew Savchenko wrote:
> On Wed, 15 May 2019 19:14:04 +0300 Andrew Savchenko wrote:
> > On Mon, 13 May 2019 11:02:40 -0500 William Hubbs wrote:
> > > On Sun, May 12, 2019 at 11:23:02PM +0300, Andrew Savchenko wrote:
> > > > On Sat, 11 May 2019 16:27:16 +0200 Andreas K. Huettel wrote:
> > > > > # Andreas K. Hüttel  (11 May 2019)
> > > > > # Outdated, EAPI=2, unmaintained, segfaults immediately.
> > > > 
> > > > Hm, it definitely doesn't segfault for me...
> > > > Works like charm right now.
> > > 
> > > ...
> > > 
> > > > If someone wants to take them, go ahead. If nobody volunteers, I'll
> > > > take at least festival and festival-ru after a few weeks.
> > > 
> > > Everything else Andreas says is correct.
> > > 
> > > Festival is outdated (2.4 is available upstream) and it is eapi 2,
> > > so if we are going to maintain it, we need to bump and move to EAPI 7,
> > > then we need to look into all of the reverse dependencies and either
> > > update or remove them.
> > > 
> > > Festival and its rdeps ar a beast, so if anyone wants to take them,
> > > be prepared for a lot of work. Please leave the accessibility project
> > > as a backup maintainer. I don't know how the sound project feels about
> > > being involved in the maintenance, so imo ask them also.
> > 
> > I can't handle everything, so let's start from something small, one
> > task per step. I think updating festival and some of its
> > localizations will be a good start.
> > 
> > I'm interesting in festival because quality of pronounced text is
> > the best I know of and sometimes I have problems with "how to
> > pronounce this stuff poperly".
> 
> Looks like I need to update app-accessibility/speech-tools as well.
> Do you mind if I'll take it as well?

For now I taken speech-tools, festival and festival-ru. Locally
updated version works, but I want to refresh patchset and include
some patches from Debian, e.g. there are known memory handling
issues in speech-tools which may be reposponsible for bug 634928 or
similar problems.

I expect stuff to be finally committed within 10 days.

Best regards,
Andrew Savchenko


pgpMHDSIlbCHQ.pgp
Description: PGP signature


Re: [gentoo-dev] last rites: app-accessibility/festival and reverse dependencies

2019-06-04 Thread Andrew Savchenko
On Wed, 15 May 2019 19:14:04 +0300 Andrew Savchenko wrote:
> On Mon, 13 May 2019 11:02:40 -0500 William Hubbs wrote:
> > On Sun, May 12, 2019 at 11:23:02PM +0300, Andrew Savchenko wrote:
> > > On Sat, 11 May 2019 16:27:16 +0200 Andreas K. Huettel wrote:
> > > > # Andreas K. Hüttel  (11 May 2019)
> > > > # Outdated, EAPI=2, unmaintained, segfaults immediately.
> > > 
> > > Hm, it definitely doesn't segfault for me...
> > > Works like charm right now.
> > 
> > ...
> > 
> > > If someone wants to take them, go ahead. If nobody volunteers, I'll
> > > take at least festival and festival-ru after a few weeks.
> > 
> > Everything else Andreas says is correct.
> > 
> > Festival is outdated (2.4 is available upstream) and it is eapi 2,
> > so if we are going to maintain it, we need to bump and move to EAPI 7,
> > then we need to look into all of the reverse dependencies and either
> > update or remove them.
> > 
> > Festival and its rdeps ar a beast, so if anyone wants to take them,
> > be prepared for a lot of work. Please leave the accessibility project
> > as a backup maintainer. I don't know how the sound project feels about
> > being involved in the maintenance, so imo ask them also.
> 
> I can't handle everything, so let's start from something small, one
> task per step. I think updating festival and some of its
> localizations will be a good start.
> 
> I'm interesting in festival because quality of pronounced text is
> the best I know of and sometimes I have problems with "how to
> pronounce this stuff poperly".

Looks like I need to update app-accessibility/speech-tools as well.
Do you mind if I'll take it as well?

Best regards,
Andrew Savchenko


pgp01CaxQ0IBq.pgp
Description: PGP signature


Re: [gentoo-dev] Announcing RISC-V

2019-05-18 Thread Andrew Savchenko
On Sat, 18 May 2019 20:47:28 +0200 Michał Górny wrote:
> On Fri, 2019-05-03 at 23:34 +0200, Andreas K. Huettel wrote:
> > * We will initially add two profiles to profile.desc: 
> >   default/linux/riscv/17.0/rv64gc/lp64d (non-multilib, 64bit hardfloat)
> >   default/linux/riscv/17.0/rv64gc (multilib lp64d/lp64, i.e. hard/softfloat)
> 
> I still don't understand the purpose of this multilib.  If you have
> a hardfloat CPU, why would you ever build some of the software
> softfloat?

One may have binary-only software which requires softfloat
dependencies.

Best regards,
Andrew Savchenko


pgpsWdRPpzuD2.pgp
Description: PGP signature


Re: [gentoo-dev] last rites: app-accessibility/festival and reverse dependencies

2019-05-15 Thread Andrew Savchenko
On Mon, 13 May 2019 11:02:40 -0500 William Hubbs wrote:
> On Sun, May 12, 2019 at 11:23:02PM +0300, Andrew Savchenko wrote:
> > On Sat, 11 May 2019 16:27:16 +0200 Andreas K. Huettel wrote:
> > > # Andreas K. Hüttel  (11 May 2019)
> > > # Outdated, EAPI=2, unmaintained, segfaults immediately.
> > 
> > Hm, it definitely doesn't segfault for me...
> > Works like charm right now.
> 
> ...
> 
> > If someone wants to take them, go ahead. If nobody volunteers, I'll
> > take at least festival and festival-ru after a few weeks.
> 
> Everything else Andreas says is correct.
> 
> Festival is outdated (2.4 is available upstream) and it is eapi 2,
> so if we are going to maintain it, we need to bump and move to EAPI 7,
> then we need to look into all of the reverse dependencies and either
> update or remove them.
> 
> Festival and its rdeps ar a beast, so if anyone wants to take them,
> be prepared for a lot of work. Please leave the accessibility project
> as a backup maintainer. I don't know how the sound project feels about
> being involved in the maintenance, so imo ask them also.

I can't handle everything, so let's start from something small, one
task per step. I think updating festival and some of its
localizations will be a good start.

I'm interesting in festival because quality of pronounced text is
the best I know of and sometimes I have problems with "how to
pronounce this stuff poperly".

Best regards,
Andrew Savchenko


pgpzDGrlMfF_l.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Rust flags

2019-05-15 Thread Andrew Savchenko
On Tue, 14 May 2019 16:58:16 -0700 Georgy Yakovlev wrote:
> On Tuesday, May 14, 2019 3:01:48 PM PDT Andrew Savchenko wrote:
> > On Tue, 14 May 2019 11:47:04 -0700 Georgy Yakovlev wrote:
[...]
> > > I have this in make.conf for quite some time.
> > > 
> > > RUSTFLAGS="-Ctarget-cpu=native -v"
> > > 
> > > it just works(tm) as you expect it to.
> > 
> > Well, it does not, at least for me. Right now I'm building
> > torbrowser from mozilla overlay and content of RUSTFLAGS from
> > make.conf doesn't show up in rustc arguments.
> > 
> That's something about mozbuild, not the variable itself.
> check about:buildconfig page of torbrowser.
> 
> RUSTFLAGS show up for me on that page, not 100% sure if they actually get 
> applied.

Yes, they are showing up, though I don't see them applied in the
build log.

> I have no idea how it calls rustc. if it's cargo then to see verbose 
> invocations you need to find where the build system calls it and add "-vv"
> 
> btw, be careful with -C opt-level=3 for ff or derivatives, it was known to 
> cause segfaults some time ago.
> 
> for regular packages this variable works fine.
> 
> > Moreover there is no mention of RUSTFLAGS in either man rustc or
> > rust/cargo eclasses.
> 
> because it's a variable used by cargo to call rustc with given params, not by 
> rustc itself.
> 
> This has nothing to do with eclass, it's cargo setting supposed to be set by 
> user.
> 
> CARGO-RUSTC(1) page does mention it
> 
> more details here:
> https://github.com/rust-lang/cargo/blob/master/src/doc/src/reference/
> environment-variables.md

Thanks, it indeed has it. I used to read man pages and man
cargo-rustc don't mention it, though github docs does.

Best regards,
Andrew Savchenko


pgp0TyN38Y2mN.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Rust flags

2019-05-14 Thread Andrew Savchenko
On Tue, 14 May 2019 11:47:04 -0700 Georgy Yakovlev wrote:
> On Tuesday, May 14, 2019 9:15:52 AM PDT Andrew Savchenko wrote:
> > Hi all!
> > 
> > Looks like rustc supports target CPU and optlevel options, e.g.
> >   rustc -C target-cpu=skylake -C opt-level=3
> > as well as more fine-grade optimizations.
> > 
> > But I see no way to specify them when building rust software.
> > Am I missing something? Is there any reason for not providing
> > something like RUSTFLAGS?
> > 
> > Best regards,
> > Andrew Savchenko
> Hi,
> 
> I have this in make.conf for quite some time.
> 
> RUSTFLAGS="-Ctarget-cpu=native -v"
> 
> it just works(tm) as you expect it to.

Well, it does not, at least for me. Right now I'm building
torbrowser from mozilla overlay and content of RUSTFLAGS from
make.conf doesn't show up in rustc arguments.

Moreover there is no mention of RUSTFLAGS in either man rustc or
rust/cargo eclasses.
 
> I remember earlier rustc/cargo were failing if same options specified twice, 
> for example once in toml files and second time via RUSTFLAGS, but I can't 
> reproduce anymore.
> Maybe it got smarter and RUSTFLAGS actually override whatever is set in toml 
> files.
> 
> 
> -
> Regards, Georgy


Best regards,
Andrew Savchenko


pgpKTeEYHHPAc.pgp
Description: PGP signature


[gentoo-dev] Rust flags

2019-05-14 Thread Andrew Savchenko
Hi all!

Looks like rustc supports target CPU and optlevel options, e.g.
  rustc -C target-cpu=skylake -C opt-level=3
as well as more fine-grade optimizations.

But I see no way to specify them when building rust software.
Am I missing something? Is there any reason for not providing
something like RUSTFLAGS?

Best regards,
Andrew Savchenko


pgp_czyREw4wl.pgp
Description: PGP signature


Re: [gentoo-dev] last rites: app-accessibility/festival and reverse dependencies

2019-05-12 Thread Andrew Savchenko
On Sat, 11 May 2019 16:27:16 +0200 Andreas K. Huettel wrote:
> # Andreas K. Hüttel  (11 May 2019)
> # Outdated, EAPI=2, unmaintained, segfaults immediately.

Hm, it definitely doesn't segfault for me...
Works like charm right now.

> # See bug 634928 and bug 612980. Removal in 30 days.
> app-accessibility/festival
> app-accessibility/festival-freebsoft-utils
> app-accessibility/festival-hts
> app-accessibility/festival-it
> app-accessibility/festival-ru
> app-accessibility/perlbox-voice
> app-accessibility/pidgin-festival
> dev-ros/sound_play

If someone wants to take them, go ahead. If nobody volunteers, I'll
take at least festival and festival-ru after a few weeks.

Best regards,
Andrew Savchenko


pgpU7a9OkXJMg.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites: dev-util/trinity

2019-04-14 Thread Andrew Savchenko
On Wed, 20 Mar 2019 21:38:42 +0100 Michał Górny wrote:
> # Michał Górny  (20 Mar 2019)
> # Unmaintained since 2015, with occasional uncoordinated updates
> # by varying developers.  The current version is outdated, and fails
> # to build.
> # Removal in 30 days.  Bug #669604.
> dev-util/trinity

The package is taken and updated, the bug №669604 is fixed.


Best regards,
Andrew Savchenko


pgpDEuyUGpPul.pgp
Description: PGP signature


Re: [gentoo-dev] Keeping net-fs/ncpfs and net-misc/ipx-utils around?

2019-03-26 Thread Andrew Savchenko
On Mon, 25 Mar 2019 15:19:06 -0400 Joshua Kinard wrote:
> Throwing a question out there on whether to keep both the net-fs/ncpfs and
> net-misc/ipx-utils packages around any longer.  Kernel upstream removed both
> the IPX (Internetwork Packet eXchange) protocol and NCPFS (NetWare Core
> Protocol Filesystem) support back in ~4.18 due to lack of maintenance.  I
> know the code in both generally worked fine back then, as I have a few
> NetWare VMs that I was able to mount filesystems from in Linux, even on my
> MIPS hardware.
> 
> However, it is effectively a dead protocol and dead filesystem for a dead
> operating system (NetWare).  I don't see anyone resurrecting IPX/NCPFS and
> updating to get it re-included it in the kernel, either.  I was tempted once
> to try, but I just don't have the time anymore.
> 
> I think we're one of the last distros to even keep IPX/NCPFS-related
> packages around long-term.  With no viable upstream for ncpfs anymore, and
> with no kernel support in Linux (or even FreeBSD; they deprecated IPX in
> ~10.0-RELEASE), I think it's time to remove this package and any related
> packages.
> 
> One catch is, sys-kernel/gentoo-sources still keeps 4.4, 4.9, and 4.14
> stable kernel series around.  These can still technically use IPX/NCPFS, and
> therefore, there might be users using it.
> 
> A quick poll of the portage tree suggests these changes are needed:
> 
> Delete USE flag reference:
> net-analyzer/hydra
> profiles/use.local.desc (remove hydra's local 'ncp' entry)
> 
> Remove ebuilds:
> net-fs/ncpfs
> net-misc/ipx-utils
> 
> Remove filesystem reference?:
> sys-apps/mlocate/files/updatedb.conf
> 
> Remove reference to 'ipx-utils':
> profiles/license_groups
> 
> 
> Thoughts?

Keep them around as long as we have kernel versions supporting
IPX/NCPFS in the tree. When they will pass, perform the cleanup
listed above. 


Best regards,
Andrew Savchenko


pgp7nZ7kgv7kd.pgp
Description: PGP signature


Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

2019-03-22 Thread Andrew Savchenko
On Fri, 22 Mar 2019 21:32:16 +0100 Piotr Karbowski wrote:
> Hi,
> 
> I'd like to discuss here the current state of elogind integration as a
> whole, and the follow-up work that is now required, after I've put a
> default on local USE flag +elogind on xorg-server while dropping default
> suid flag in my commit yesterday.
> 
> The motivation on the changes was to follow up the removal of default
> +suid that happened in November last years, that sadly had to be
> reverted. Now with elogind integration, non-systemd users got all that
> they need to run Xorg as a unprivileged user.
> 
> The status of xorg-server at this very moment is that it no longer
> defaults to be merged with suid, however, now it defaults to +elogind.
> This have the following implications:
> 
> - User will be prompted that pambase requires +elogind, which is not
> enabled by default -- meaning that simple `emerge xorg-server` will
> prompt user to add package.use entry. This could be solved by always
> having the elogind bits enabled, the same way a gnome-keyring is, so the
> pam_elogind.so is used if present. This shouldn't have any negative
> effect on for instance systemd users, as systemd cannot be installed at
> the same time as elogind.
> 
> - systemd users that does not use systemd profiles will be required to
> alter package.use or make.conf USE flags definition to drop -elogind
> there, as otherwise xorg-server will refuse to be merged due to
> at-most-one-of ( elogind systemd ) condition there. However those
> systemd users that do use systemd profiles will not run into any things
> to do, as systemd's use.mask have elogind there.
> 
> - The desktop profiles enables +consolekit, which conflicts with elogind
> -- the users of those profiles will need to adjust USE flags.
> 
> - OpenRC/non-systemd users are now able to run X without suid, as
> elogind is the entity that wraps the SETMASTER, no more "ioctl
> permission denied" on starting X as unprivileged user.
> 
> After speaking with some of you on #-dev and #-desktop I know that the
> opinions on that vary, arguably enabling elogind local USE flag on
> xorg-server was somewhat ahead of time, leaving some users in
> unfavorable position where the xorg-server installation will require
> them to manually modify package.use/make.conf.
> 
> Some of the ideas that were pointed on IRC (forgive me if I missed some):
> 
> - We should go back to +suid -elogind default.
> - We should actually NOT put suid on Xorg if USE="suid elogind" but put
> suid bit with USE="suid -elogind".
> - We should only ever enable elogind in desktop profiles.
> 
> Personally I'd like to stay without enabling suid by default on
> xorg-server, as otherwise hardly anyone will ever drop the suid from it,
> which would be a big step back. Gentoo tried to drop suid from
> xorg-server a handful of times, let's make the current one a final one :)
> 
> I'd like to propose doing the following:
> 
> - Keywording elogind on missing archs
> - Making elogind a global USE flag
> - Switching desktop profiles to elogind from consolekit while still
> preserving -suid +elogind on xorg-server for those that does not use
> desktop profiles (systemd profiles users not affected)
> - Making pambase always install the configuration for pam_elogind.so,
> the same way it does for pam_gnome_keyring.so at this very moment,
> effectively removing elogind USE flag from it.

Maybe that's a good time to make USE flag for pam_gnome_keyring.so.
Really, we shouldn't force users with some crap just "because it
doesn't hurt (much)".
 
> What do you all think about?

Currently PAM warns if more than single session tracker is enabled
(consolekit, elogind, systemd). Enabling one implicitly by default
will likely create problems for users of other session tracker.

As for me personally, I do not use session trackers at all, they
are banned from all my setups for good. Though as long as this is
configurable, I don't really care about defaults.

Best regards,
Andrew Savchenko


pgpU74agEv0xv.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites: dev-util/staruml-bin

2019-03-18 Thread Andrew Savchenko
On Mon, 18 Mar 2019 18:09:47 +0100 Michał Górny wrote:
> On Mon, 2019-03-18 at 19:30 +0300, Andrew Savchenko wrote:
> > On Mon, 18 Mar 2019 16:09:18 +0100 Michał Górny wrote:
> > > On Sun, 2019-03-17 at 11:30 +0300, Andrew Savchenko wrote:
> > > > On Sat, 16 Mar 2019 18:38:48 +0100 Michał Górny wrote:
> > > > > On Sat, 2019-03-16 at 13:14 +0300, Andrew Savchenko wrote:
> > > > > > On Sat, 16 Mar 2019 10:35:18 +0100 Michał Górny wrote:
> > > > > > > On Sat, 2019-03-16 at 09:31 +, James Le Cuirot wrote:
> > > > > > > > On Fri, 15 Mar 2019 10:23:00 +0100
> > > > > > > > Michał Górny  wrote:
> > > > > > > > 
> > > > > > > > > # Michał Górny  (15 Mar 2019)
> > > > > > > > > # Last reverse dependency of dev-libs/libgcrypt-1.5* 
> > > > > > > > > (#656378).  Current
> > > > > > > > > # version is outdated, maintainer is MIA and the new versions 
> > > > > > > > > are
> > > > > > > > > # in distro-unfriendly AppImage format (#661740).
> > > > > > > > > # Removal in 30 days.  Bug #677486.
> > > > > > > > > dev-util/staruml-bin
> > > > > > > > > =dev-libs/libgcrypt-1.5*
> > > > > > > > 
> > > > > > > > I don't care about staruml-bin but libgcrypt is one of those 
> > > > > > > > legacy
> > > > > > > > libraries that would be helpful to keep around for older 
> > > > > > > > proprietary
> > > > > > > > software that is not in the tree. In particular, it is used by
> > > > > > > > Half-Life 2 and Portal, not exactly obscure games. It is 
> > > > > > > > included in
> > > > > > > > the Steam runtime but we highly recommend against using that 
> > > > > > > > because it
> > > > > > > > causes many issues.
> > > > > > > 
> > > > > > > I don't understand why would you want to run some proprietary 
> > > > > > > native
> > > > > > > executables requiring obsolete libraries on your system when HL2 
> > > > > > > works
> > > > > > > perfectly via wine, and gets a nice performance boost via Gallium 
> > > > > > > Nine.
> > > > > > 
> > > > > > Because native code works faster than API emulation via wine.
> > > > > > 
> > > > > 
> > > > > Do you have any data to support that?  Or is it 'obvious'?
> > > > 
> > > > Yes, I have. Because Half-Life 2 on native steam works on my old
> > > > box with GF 7300 and Athlon-XP and does not work at all on the
> > > > same box via wine-d3d9.
> > > > 
> > > 
> > > That's not really a data point.  Unless you can actually test it (or
> > > otherwise prove that it would be slower if it worked), you're merely
> > > complaining that you can't use the faster solution.
> > > 
> > > I'm sorry that you've bought non-OSS-friendly video card and now you're
> > > stuck with the choice between awful proprietary drivers and far-from-
> > > complete OSS drivers.  However, that doesn't prove that the native
> > > version would be faster at all.
> > 
> > If wine-based version does not work, its performance is zero. That's
> > why the native version is faster. 
> > 
> 
> Wrong.  If it doesn't work, it consumes very little CPU/GPU cycles. 
> Therefore, it is much more efficient than the working version.
 
But it hangs, consuming all CPU cycles possible.

Best regards,
Andrew Savchenko


pgp_y7DzD0kOU.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites: dev-util/staruml-bin

2019-03-18 Thread Andrew Savchenko
On Mon, 18 Mar 2019 16:09:18 +0100 Michał Górny wrote:
> On Sun, 2019-03-17 at 11:30 +0300, Andrew Savchenko wrote:
> > On Sat, 16 Mar 2019 18:38:48 +0100 Michał Górny wrote:
> > > On Sat, 2019-03-16 at 13:14 +0300, Andrew Savchenko wrote:
> > > > On Sat, 16 Mar 2019 10:35:18 +0100 Michał Górny wrote:
> > > > > On Sat, 2019-03-16 at 09:31 +, James Le Cuirot wrote:
> > > > > > On Fri, 15 Mar 2019 10:23:00 +0100
> > > > > > Michał Górny  wrote:
> > > > > > 
> > > > > > > # Michał Górny  (15 Mar 2019)
> > > > > > > # Last reverse dependency of dev-libs/libgcrypt-1.5* (#656378).  
> > > > > > > Current
> > > > > > > # version is outdated, maintainer is MIA and the new versions are
> > > > > > > # in distro-unfriendly AppImage format (#661740).
> > > > > > > # Removal in 30 days.  Bug #677486.
> > > > > > > dev-util/staruml-bin
> > > > > > > =dev-libs/libgcrypt-1.5*
> > > > > > 
> > > > > > I don't care about staruml-bin but libgcrypt is one of those legacy
> > > > > > libraries that would be helpful to keep around for older proprietary
> > > > > > software that is not in the tree. In particular, it is used by
> > > > > > Half-Life 2 and Portal, not exactly obscure games. It is included in
> > > > > > the Steam runtime but we highly recommend against using that 
> > > > > > because it
> > > > > > causes many issues.
> > > > > 
> > > > > I don't understand why would you want to run some proprietary native
> > > > > executables requiring obsolete libraries on your system when HL2 works
> > > > > perfectly via wine, and gets a nice performance boost via Gallium 
> > > > > Nine.
> > > > 
> > > > Because native code works faster than API emulation via wine.
> > > > 
> > > 
> > > Do you have any data to support that?  Or is it 'obvious'?
> > 
> > Yes, I have. Because Half-Life 2 on native steam works on my old
> > box with GF 7300 and Athlon-XP and does not work at all on the
> > same box via wine-d3d9.
> > 
> 
> That's not really a data point.  Unless you can actually test it (or
> otherwise prove that it would be slower if it worked), you're merely
> complaining that you can't use the faster solution.
> 
> I'm sorry that you've bought non-OSS-friendly video card and now you're
> stuck with the choice between awful proprietary drivers and far-from-
> complete OSS drivers.  However, that doesn't prove that the native
> version would be faster at all.

If wine-based version does not work, its performance is zero. That's
why the native version is faster. 

Best regards,
Andrew Savchenko


pgpJ9MQEEaihv.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites: dev-util/staruml-bin

2019-03-17 Thread Andrew Savchenko
On Sat, 16 Mar 2019 18:38:48 +0100 Michał Górny wrote:
> On Sat, 2019-03-16 at 13:14 +0300, Andrew Savchenko wrote:
> > On Sat, 16 Mar 2019 10:35:18 +0100 Michał Górny wrote:
> > > On Sat, 2019-03-16 at 09:31 +, James Le Cuirot wrote:
> > > > On Fri, 15 Mar 2019 10:23:00 +0100
> > > > Michał Górny  wrote:
> > > > 
> > > > > # Michał Górny  (15 Mar 2019)
> > > > > # Last reverse dependency of dev-libs/libgcrypt-1.5* (#656378).  
> > > > > Current
> > > > > # version is outdated, maintainer is MIA and the new versions are
> > > > > # in distro-unfriendly AppImage format (#661740).
> > > > > # Removal in 30 days.  Bug #677486.
> > > > > dev-util/staruml-bin
> > > > > =dev-libs/libgcrypt-1.5*
> > > > 
> > > > I don't care about staruml-bin but libgcrypt is one of those legacy
> > > > libraries that would be helpful to keep around for older proprietary
> > > > software that is not in the tree. In particular, it is used by
> > > > Half-Life 2 and Portal, not exactly obscure games. It is included in
> > > > the Steam runtime but we highly recommend against using that because it
> > > > causes many issues.
> > > 
> > > I don't understand why would you want to run some proprietary native
> > > executables requiring obsolete libraries on your system when HL2 works
> > > perfectly via wine, and gets a nice performance boost via Gallium Nine.
> > 
> > Because native code works faster than API emulation via wine.
> > 
> 
> Do you have any data to support that?  Or is it 'obvious'?

Yes, I have. Because Half-Life 2 on native steam works on my old
box with GF 7300 and Athlon-XP and does not work at all on the
same box via wine-d3d9.

Best regards,
Andrew Savchenko


pgpAKr_tgIuRZ.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites: dev-util/staruml-bin

2019-03-16 Thread Andrew Savchenko
On Sat, 16 Mar 2019 10:35:18 +0100 Michał Górny wrote:
> On Sat, 2019-03-16 at 09:31 +, James Le Cuirot wrote:
> > On Fri, 15 Mar 2019 10:23:00 +0100
> > Michał Górny  wrote:
> > 
> > > # Michał Górny  (15 Mar 2019)
> > > # Last reverse dependency of dev-libs/libgcrypt-1.5* (#656378).  Current
> > > # version is outdated, maintainer is MIA and the new versions are
> > > # in distro-unfriendly AppImage format (#661740).
> > > # Removal in 30 days.  Bug #677486.
> > > dev-util/staruml-bin
> > > =dev-libs/libgcrypt-1.5*
> > 
> > I don't care about staruml-bin but libgcrypt is one of those legacy
> > libraries that would be helpful to keep around for older proprietary
> > software that is not in the tree. In particular, it is used by
> > Half-Life 2 and Portal, not exactly obscure games. It is included in
> > the Steam runtime but we highly recommend against using that because it
> > causes many issues.
> 
> I don't understand why would you want to run some proprietary native
> executables requiring obsolete libraries on your system when HL2 works
> perfectly via wine, and gets a nice performance boost via Gallium Nine.

Because native code works faster than API emulation via wine.

Best regards,
Andrew Savchenko


pgpiKuOiQn6T8.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

2019-02-23 Thread Andrew Savchenko
On Fri, 22 Feb 2019 23:30:15 -0500 desultory wrote:
> On 02/20/19 02:36, Michał Górny wrote:
> > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> >>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
> >>
> >>  
> >>>   # Don't install libtool archives (even for modules)
> >>> - prune_libtool_files --all
> >>> + find "${D}" -name '*.la' -delete || die
> >>
> >> Maybe restrict removal to regular files, i.e. add "-type f"?
> > 
> > I suppose you should have spoken up when people started adopting that
> > 'find' line all over the place.  Though I honestly doubt we're going to
> > see many packages installing '*.la' non-files.
> > 
> Just so we are all clear here: your argument is that more fully correct
> approaches should not be considered in the present and future because
> less fully correct approaches were implemented in the past? And,
> further, that since nothing matching a specific pattern happens to come
> to your mind at he moment, such things do not exist? Perhaps dialing
> back the rhetoric from 11 and considering feedback as an opportunity to
> improve existing code is called for in this case, among others.

If we are going to improve code, we should also use find -O3. 


Best regards,
Andrew Savchenko


pgpYzt5V5fzvl.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support

2019-02-22 Thread Andrew Savchenko
On Tue, 19 Feb 2019 22:46:23 -0800 Matt Turner wrote:
> On Tue, Feb 19, 2019 at 10:24 PM Ulrich Mueller  wrote:
> >
> > >>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
> >
> > > Nearly all the work is just removing uses of autotools-multilib and
> > > autotools-utils. The new code should work in EAPI 4 and 5. Don't add
> > > support for EAPI 6; that ship has already sailed.
> >
> > AFAICS, adding EAPI 6 support wouldn't require any additional code?
> 
> I think that is true. (I have no strong preference on whether to add
> EAPI 6 support. I just figured that anything that gets an EAPI bump
> now should go to the latest available)

This is not always possible. E.g. I have a package with optional
java support. Since java is still EAPI 6 I can't use EAPI 7.

Best regards,
Andrew Savchenko


pgpKvbXTHcFp8.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Replacing binary-only SLOTs with separate packages

2019-01-19 Thread Andrew Savchenko
On Fri, 18 Jan 2019 21:13:34 +0100 Michał Górny wrote:
> Hello,
> 
> Since I've been working on the early gx86-multilib, we've been using
> 'binary-only SLOTs' to support providing old versions of libraries for
> prebuilt software.  I think this was a bad idea, and I'd like to suggest
> replacing it with something cleaner, for the reasons outlined below.
> 
> 
> Current state
> =
> 
> Let's take dev-libs/openssl as an example.  This package has three SLOTs
> right now:
> 
>   0.9.8: 0.9.8z_p8-r1
>   1.0.0: 1.0.2q-r200
>   0: 1.0.2q 1.1.0j 1.1.1a 1.1.1a-r1
> 
> The real package is provided as slot :0, that includes all libraries,
> headers and executables.  Slots 0.9.8 and 1.0.0 only install .so.N*
> libraries that can be used to satisfy dependencies of prebuilt packages.
> 
> 
> Problems with the current state
> ===
> 
> Firstly, it is confusing to developers.  Let's analyze the dependencies
> on dev-libs/openssl.  A quick grep reveals seven patterns.  They are
> listed below, along with occurrence counts and percentages:
> 
>   dev-libs/openssl  2787.8%  }
>   dev-libs/openssl:* 491.4%  } 14.2%
>   dev-libs/openssl:=1785.0%  }
>   dev-libs/openssl:0660   18.6%
>   dev-libs/openssl:0=  2381   67.0%
>   dev-libs/openssl:0/040.1%
>   dev-libs/openssl:0/1.1  20.1%
> 
> (note that those are rough measures, not guaranteed to be precise)
> 
> So apparently 14.2% of dependencies allow any slot of OpenSSL which is
> most likely wrong, and 1.4% explicitly claim that's what the package
> wants.  This could be valid only if e.g. the package supported multiple
> ABIs of OpenSSL libraries and used dlopen() with a few possible SONAMEs
> which I honestly doubt any of those packages is doing.
> 
> In other words, 14.2% of dependencies on OpenSSL are plain wrong,
> and 6.4% are wrong in a way that isn't going to be reported by repoman. 
> 1.4% of cases are using ':*' which probably indicates the developer
> decided to silence repoman without understanding how slot operators work
> which is a horrible thing from QA perspective.
> 
> We also have a few cases that require specific OpenSSL subslot (e.g.
> forcing old version into :0 slot) but *none* actually using the binary
> compatibility slots.
> 
> 
> Secondly, it is confusing to users.  If we remove old versions and only
> keep binary compatibility slots, users can be easily tricked into
> installing them and being surprised it's not a complete package.  If we
> keep old versions, we end up having different revisions of the same
> version in different slots which is also easily confused.
> 
> 
> Thirdly, it is cumbersome to introduce.  If we are to introduce a binary
> compatibility slot for a package that didn't have it, we need to update
> all reverse dependencies.  This usually means researching whether we
> should use ':0' or ':0=', and if we get this wrong, we just silence
> repoman warning about missing slot-op.
> 
> 
> All of this considered, I can't think of a single real benefit of using
> slots for this purpose.  They work but there's nothing really special
> about them.
> 
> 
> Suggested replacement
> =
> 
> My suggestion is to move binary compatibility slots into separate
> packages.  For example, dev-libs/openssl would be split into:
> 
>   dev-libs/openssl  -- containing the actual package
> 
>   dev-libs/openssl-bin-compat  -- containing binary compatibility slots
> 
> In this case, all dependencies on dev-libs/openssl would become correct
> (or semi-correct, wrt missing := dep) again.  Since packages are co-
> installable the same way slots are, there is no loss there.  Since
> nothing depends on binary compatibility slots, we do not even need to
> update anything (but if we had, the update cost would be minimal both to
> developers and to users).
> 
> 
> What do you think?

I do not like the idea. Slots are very elegant and effective
mechanism and is one of the points where Gentoo outruns other
distributions. Proposed approach with compat packages will
effectively disable slots for most cases.

Also proposed change will create a lot of unneeded technical
difficulties in maintaining packages: there will be double ebuilds
to maintain instead of a single one, ${PN} references will be
broken without additional changes and so far and so on. A lot of
unnecessary rebuilds will happen due slot to package moves.

Aside from development questions for me in a role of sysadmin slots
are much easier and understandable to manage than zoo of *compat*
packages in other distributions.

Assumption that :* is always wrong is invalid, since there are
valid cases: there are apps supporting various API versions or
using tools/data files without any care from where they are coming.

Best regards,
Andrew Savchenko


pgp_NgTFIUqMp.pgp
Description: PGP signature


[gentoo-dev] Call for GSoC 2019 ideas and mentors

2019-01-17 Thread Andrew Savchenko
Hi all!

As always, Gentoo plans to participate in the Google Summer of Code
2019. We are looking for new project ideas and are always open for
new mentors.

1. Project ideas

GSoC projects should be suitable for 3 months worth of work for
a student, taking into account time required for students to get in
touch with the project, to learn some details, to fix mistakes and
make improvements. Most students are not yet seasoned developers,
so their coding rate will be likely slower than yours.

Usually projects are something more complicated than just writing
some ebuilds, however if non-trivial ebuild related work is
required, e.g. to write new eclasses and adapt existing packages to
use them (or add new ones), this should do too.

Ideas from previous years may be reused, but this should not be
abused, since Gentoo moves forward and we have new stuff to do.

If you have an idea, but can't be a mentor, please still tell us
about it, we'll try to find a mentor later.

Ideas should be put to our wiki: [1].
The page contains ideas adding howto.

2. Mentors

If you want to be a mentor, welcome! It is not necessary to be a
Gentoo developer in order to be a mentor, but project must be
Gentoo related.

Mentoring requires some time. It depends much on a student, but is
usually within 4-10 hours per week. If you don't have that much
time, but still want to help, you may become a backup mentor.
Students often have 2 mentors to eliminate bus factor and to
improve expertise in a project.

Please keep in mind that GSoC is not just about new code, but about
bringing new people to community and we have developers which where
GSoC students in the past. So time invested in students will result
not only in some problems solved, but into bringing new people to
our community and strengthening ties with existing participants.

Mentors should enlist themselves on the wiki: [2].

If you have any questions or proposals, feel free to reply to this
e-mail, or contact us via #gentoo-soc IRC channel on FreeNode[3],
or by writing to project's alias[4].

[1] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2019/Ideas
[2] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2019/Mentors
[3] http://webchat.freenode.net/?channels=gentoo-soc
[4] mailto:soc-ment...@gentoo.org

Best regards,
Andrew Savchenko


pgpYAAeaTFWcc.pgp
Description: PGP signature


Re: [gentoo-dev] rfc: hwclock service in OpenRC

2018-12-15 Thread Andrew Savchenko
Hi!

On Thu, 13 Dec 2018 12:18:26 -0600 William Hubbs wrote:
> All,
> 
> the hwclock service is Linux specific, so all of this applies only to
> OpenRC on Linux.
> 
> OpenRC currently adds the hwclock service to the boot runlevel upstream.
> The linux kernel also has had a way for some time to handle the clock
> itself if you have an RTC.
> 
> Is it reasonable to stop adding the hwclock service to the boot runlevel
> upstream and documenting the options and asking users to make that
> choice?

Yes, it is. CONFIG_RTC_HCTOSYS (and CONFIG_RTC_SYSTOHC) is
available in kernel for years and should be a preferred way to
handle the clock.

Best regards,
Andrew Savchenko


pgpg2tlANZzJC.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v3 2/2] fortran-2.eclass: support EAPI 7

2018-11-17 Thread Andrew Savchenko
On Mon, 5 Nov 2018 18:37:55 +0300 Andrew Savchenko wrote:
> Hi all!
> 
> Here follow updated patches for fortran-2.eclass EAPI 7 update.
> 
> Patch 2 contains only code cleanup and fixes unrelated to EAPI 7
> update:

With no comments for ~12 days both patches are applied now.

Best regards,
Andrew Savchenko


pgpZF42GEkxsK.pgp
Description: PGP signature


Re: [gentoo-dev] Lastrites: x11-libs/gksu, x11-libs/libgksu, dev-java/ant-nodeps, dev-java/ant-trax, app-admin/localepurge, net-p2p/ppcoind, media-libs/libptp2, sci-libs/spqr...

2018-11-11 Thread Andrew Savchenko
Hi all,

> # Pacho Ramos  (11 Nov 2018)
> # Unmaintained, upstream dead, fails to build (#650084). Removal in a month.
> sys-power/suspend

1. It it maintaned and works fine except for splashutils support
which is going to be treecleaned. It doesn't matter if upstream is
active or not if a software works.

2. The mentioned bug is not a valid reason because it is manifested
only with splashutils support enabled.

3. I revbumped suspend to drop fbsplash support.

4. Package mask is dropped.

Best regards,
Andrew Savchenko


pgpPi3bpl1n_E.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v3 2/2] fortran-2.eclass: support EAPI 7

2018-11-05 Thread Andrew Savchenko
Hi all!

Here follow updated patches for fortran-2.eclass EAPI 7 update.

Patch 2 contains only code cleanup and fixes unrelated to EAPI 7
update:

diff --git a/eclass/fortran-2.eclass b/eclass/fortran-2.eclass
index 820cbbcb49bd..b871d16e3e05 100644
--- a/eclass/fortran-2.eclass
+++ b/eclass/fortran-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: fortran-2.eclass
@@ -92,7 +95,7 @@ unset _f_use
 fortran_int64_abi_fflags() {
debug-print-function ${FUNCNAME} "${@}"
 
-   _FC=$(tc-getFC)
+   local _FC=$(tc-getFC)
if [[ ${_FC} == *gfortran* ]]; then
echo "-fdefault-integer-8"
elif [[ ${_FC} == ifort ]]; then
@@ -112,17 +115,17 @@ _fortran_write_testsuite() {
local filebase=${T}/test-fortran
 
# f77 code
-   cat <<- EOF > "${filebase}.f"
+   cat <<- EOF > "${filebase}.f" || die
   end
EOF
 
# f90/95 code
-   cat <<- EOF > "${filebase}.f90"
+   cat <<- EOF > "${filebase}.f90" || die
end
EOF
 
# f2003 code
-   cat <<- EOF > "${filebase}.f03"
+   cat <<- EOF > "${filebase}.f03" || die
   procedure(), pointer :: p
   end
EOF
@@ -170,7 +173,7 @@ _fortran-has-openmp() {
local ret
local _fc=$(tc-getFC)
 
-   cat <<- EOF > "${fcode}"
+   cat <<- EOF > "${fcode}" || die
   call omp_get_num_threads
   end
EOF
@@ -179,7 +182,7 @@ _fortran-has-openmp() {
${_fc} ${flag} "${fcode}" -o "${fcode}.x" \
&>> "${T}"/_fortran_compile_test.log
ret=$?
-   (( ${ret} )) || break
+   [[ ${ret} == 0 ]] && break
done
 
rm -f "${fcode}.x"
@@ -193,12 +196,12 @@ _fortran-has-openmp() {
 _fortran_die_msg() {
debug-print-function ${FUNCNAME} "${@}"
 
-   echo
+   eerror
eerror "Please install currently selected gcc version with USE=fortran."
eerror "If you intend to use a different compiler then gfortran, please"
eerror "set FC variable accordingly and take care that the necessary"
eerror "fortran dialects are supported."
-   echo
+   eerror
die "Currently no working fortran compiler is available (see 
${T}/_fortran_compile_test.log for information)"
 }
 
@@ -250,7 +253,7 @@ _fortran-2_pkg_setup() {
for _f_use in ${FORTRAN_NEEDED}; do
case ${_f_use} in
always)
-   _fortran_test_function && break
+   _fortran_test_function && break 2
;;
no)
einfo "Forcing fortran support off"
@@ -258,7 +261,7 @@ _fortran-2_pkg_setup() {
;;
    *)
    if use ${_f_use}; then
-   _fortran_test_function && break
+   _fortran_test_function && break 2
else
unset FC
unset F77


Best regards,
Andrew Savchenko


pgpVjVjanKV36.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] fortran-2.eclass: support EAPI 7

2018-11-05 Thread Andrew Savchenko
On Fri, 02 Nov 2018 15:20:16 +0100 Michał Górny wrote:
> On Fri, 2018-11-02 at 01:27 +0300, Andrew Savchenko wrote:
> > Hi!
> > 
> > On Tue, 30 Oct 2018 08:18:58 +0100 Michał Górny wrote:
> > > On Mon, 2018-10-29 at 03:57 +0300, Andrew Savchenko wrote:
> > > > On Sun, 28 Oct 2018 19:29:28 +0100 Michał Górny wrote:
> > > > > On Sun, 2018-10-28 at 01:38 +0300, Andrew Savchenko wrote:
> > > > > > Hi all!
> > > > > > 
> > > > > > The only blocker for EAPI 7 update is eutils inheritance, but it
> > > > > > seems to be not used within the current eclass code, probably a
> > > > > > remnant from older days. So it is removed.
> > > > > > 
> > > > > > Looks like no other EAPI 7 specific changes needed.
> > > > > > 
> > > > > 
> > > > > Please use -U9 to include more context to the patches.
> > > 
> > > I'm going to include a few 'easy cleanup' comments since EAPI 7
> > > is a good opportunity to improve the eclass.  I'm going to skip horribly
> > > bad design decisions since I suppose nobody cares.
> > 
> > Should we really mix EAPI bump with full code review?
> 
> Yes, for two reasons.
> 
> Firstly, because an EAPI bump effectively requires reviewing all
> the eclass logic for constraints imposed by the new EAPI.  While
> reviewing code, it is natural that people may notice other issues. 
> Ignoring them once noticed would be a waste of effort.

EAPI update usually don't affect full ebuild scope. For EAPI 6->7
update grep is sufficient to find affected parts of the eclass.

> Secondly, changes to frequently used eclass have a large overhead of
> metadata cache updates.  Given most of the listed issues are rather
> trivial to fix, it would be wasteful to defer them for a second metadata
> cache update.

Not all eclasses are frequently used, including fortran-2 eclass.

> > So I kindly ask you for future updates (from everyone, not just
> > me) focus on review of the proposed changes instead of reviewing
> > full code. Thank you for understanding.
> 
> As explained above, the proposed change is meaningless without context
> (as it affects how everything else in eclass works).  If we were to
> ignore context, we'd even ACK eclass changes that resulted in the eclass
> immediately dying due to programmer's mistake.
> 
> Finally, I'd like to point out that peer review is one of foundations
> of open source.

While peer review is important in many cases, the statement above
is wrong. The free software (and not just open source and Gentoo
is free software) founds on the four freedoms as defined by FSF.

> Sadly, Gentoo has failed to embrace this, and right now reviews
> of existing code are rather an exception than a rule.  What
> makes it even worse is that some developers are actively hostile to
> the criticism of their code.

Everything is good only within sane limits. While peer review is
often useful, it may be harmful as well:

1) It at least doubles human time required to do the job. And human
resources are the only resources we are really short of.

2) Sometimes it turns into bikeshedding, e.g. of how variables
should be named or what indentation style should be used.

3) Unreasonably long and complicated process for routine changes
may discourage people from further contributions. Right now we have
dozens of eclasses still on EAPI 6. I would prefer to see them
EAPI 7 so they would not block EAPI 7 updates of dependent packages,
rather than require them to underdo complete overhaul during EAPI 7
update effectively postponing it for a long time.

Sometimes the best is the enemy of the good.

Best regards,
Andrew Savchenko


pgp3r5xBITfwc.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] fortran-2.eclass: support EAPI 7

2018-11-05 Thread Andrew Savchenko
On Fri, 02 Nov 2018 11:27:29 +0100 Ulrich Mueller wrote:
> >>>>> On Thu, 01 Nov 2018, Andrew Savchenko wrote:
>  
> > -inherit eutils toolchain-funcs
> > +inherit toolchain-funcs
> > +case ${EAPI:-0} in
> > +   # not used in the eclass, but left for backward compatibility with 
> > legacy users
> > +   4|5|6) inherit eutils ;;
> > +   7) ;;
> > +   *) die "EAPI=${EAPI} is not supported" ;;
> > +esac
> >  
> >  case ${EAPI:-0} in
> > -   4|5|6) EXPORT_FUNCTIONS pkg_setup ;;
> > +   4|5|6|7) EXPORT_FUNCTIONS pkg_setup ;;
> > *) die "EAPI=${EAPI} is not supported" ;;
> >  esac
> 
> Why is the second case statement needed? Program flow can only reach it
> if the EAPI is 4, 5, 6, or 7.

Just a remnant from older version. Fixed.

Best regards,
Andrew Savchenko


pgp3a27iuBHbf.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v3 1/2] fortran-2.eclass: support EAPI 7

2018-11-05 Thread Andrew Savchenko
Hi all!

Here follow updated patches for fortran-2.eclass EAPI 7 update.

Patch 1 contains only EAPI 7 related changes:

diff --git a/eclass/fortran-2.eclass b/eclass/fortran-2.eclass
index 820cbbcb49bd..b871d16e3e05 100644
--- a/eclass/fortran-2.eclass
+++ b/eclass/fortran-2.eclass
@@ -8,7 +8,7 @@
 # @AUTHOR:
 # Author Justin Lecher 
 # Test functions provided by Sebastien Fabbro and Kacper Kowalik
-# @SUPPORTED_EAPIS: 4 5 6
+# @SUPPORTED_EAPIS: 4 5 6 7
 # @BLURB: Simplify fortran compiler management
 # @DESCRIPTION:
 # If you need a fortran compiler, then you should be inheriting
this eclass. @@ -27,13 +27,16 @@
 #
 # FORTRAN_NEED_OPENMP=1
 
-inherit eutils toolchain-funcs
-
+inherit toolchain-funcs
 case ${EAPI:-0} in
-   4|5|6) EXPORT_FUNCTIONS pkg_setup ;;
+   # not used in the eclass, but left for backward
compatibility with legacy users
+   4|5|6) inherit eutils ;;
+   7) ;;
*) die "EAPI=${EAPI} is not supported" ;;
 esac
 
+EXPORT_FUNCTIONS pkg_setup
+
 if [[ ! ${_FORTRAN_2_CLASS} ]]; then
 
 # @ECLASS-VARIABLE: FORTRAN_NEED_OPENMP


Best regards,
Andrew Savchenko


pgph7FaFP8gYk.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] fortran-2.eclass: support EAPI 7

2018-11-01 Thread Andrew Savchenko
Hi!

On Tue, 30 Oct 2018 08:18:58 +0100 Michał Górny wrote:
> On Mon, 2018-10-29 at 03:57 +0300, Andrew Savchenko wrote:
> > On Sun, 28 Oct 2018 19:29:28 +0100 Michał Górny wrote:
> > > On Sun, 2018-10-28 at 01:38 +0300, Andrew Savchenko wrote:
> > > > Hi all!
> > > > 
> > > > The only blocker for EAPI 7 update is eutils inheritance, but it
> > > > seems to be not used within the current eclass code, probably a
> > > > remnant from older days. So it is removed.
> > > > 
> > > > Looks like no other EAPI 7 specific changes needed.
> > > > 
> > > 
> > > Please use -U9 to include more context to the patches.
> 
> I'm going to include a few 'easy cleanup' comments since EAPI 7
> is a good opportunity to improve the eclass.  I'm going to skip horribly
> bad design decisions since I suppose nobody cares.

Should we really mix EAPI bump with full code review?

This eclass is small, so no harm here. But for larger eclasses
(hello java-*.eclass) this will hinder updates considerably. I
prefer to fix something rather than to fix nothing while
frustrating in attempt to fix everything at once.

Also this make git history review harder as fixes for independent
issues will be mixed together.

So I kindly ask you for future updates (from everyone, not just
me) focus on review of the proposed changes instead of reviewing
full code. Thank you for understanding.

> >  # @FUNCTION: fortran_int64_abi_fflags
> >  # @DESCRIPTION:
> >  # Return the Fortran compiler flag to enable 64 bit integers for
> >  # array indices
> >  # @CODE
> >  fortran_int64_abi_fflags() {
> > debug-print-function ${FUNCNAME} "${@}"
> >  
> > _FC=$(tc-getFC)
> 
> Any reason not to make it local?

Fixed.
 
> >  # @FUNCTION: _fortran_write_testsuite
> >  # @INTERNAL
> >  # @DESCRIPTION:
> >  # writes fortran test code
> >  _fortran_write_testsuite() {
> > debug-print-function ${FUNCNAME} "${@}"
> >  
> > local filebase=${T}/test-fortran
> >  
> > # f77 code
> > cat <<- EOF > "${filebase}.f"
> 
> || die

Done.

> >end
> > EOF
> >  
> > # f90/95 code
> > cat <<- EOF > "${filebase}.f90"
> 
> || die

Done.

> > end
> 
> Also, why different indentation?

I prefer not to touch it. Fortran compilers are quite picky with
leading spaces or tabs.

> > EOF
> >  
> > # f2003 code
> > cat <<- EOF > "${filebase}.f03"
> 
> || die

Done.

> >  # @FUNCTION: _fortran-has-openmp
> >  # @RETURN: return code of the compiler
> >  # @INTERNAL
> >  # @DESCRIPTION:
> >  # See if the fortran supports OpenMP.
> >  _fortran-has-openmp() {
> > debug-print-function ${FUNCNAME} "${@}"
> >  
> > local flag
> > local filebase=${T}/test-fc-openmp
> > local fcode=${filebase}.f
> > local ret
> > local _fc=$(tc-getFC)
> >  
> > cat <<- EOF > "${fcode}"
> 
> || die

Done.
 
> > for flag in -fopenmp -xopenmp -openmp -mp -omp -qsmp=omp; do
> > ${_fc} ${flag} "${fcode}" -o "${fcode}.x" \
> > &>> "${T}"/_fortran_compile_test.log
> > ret=$?
> > (( ${ret} )) || break
> 
> This (( ... )) is unreadable at best; please replace it with clear
> condition.

Fixed. ret variable is not needed at all.

> >  # @FUNCTION: _fortran_die_msg
> >  # @INTERNAL
> >  # @DESCRIPTION:
> >  # Detailed description how to handle fortran support
> >  _fortran_die_msg() {
> > debug-print-function ${FUNCNAME} "${@}"
> >  
> > echo
> 
> Don't mix echo with eerror.

Done.

> >  # @FUNCTION: _fortran-2_pkg_setup
> >  # @INTERNAL
> >  # @DESCRIPTION:
> >  # _The_ fortran-2_pkg_setup() code
> >  _fortran-2_pkg_setup() {
> > for _f_use in ${FORTRAN_NEEDED}; do
> > case ${_f_use} in
> > always)
> > _fortran_test_function && break
> > ;;
> > no)
> > einfo "Forcing fortran support off"
> > break
> > ;;
> > *)
> > if use ${_f_use}; then
> > _fortran_test_function && break
> > else
> > unset FC
> > unset F77
> > fi
> 
> This contradicts the dependency atoms.
> 
> If FORTRAN_NEEDED="foo bar", you'll get:
> 
>   DEP="foo? ( virtual/fortran ) bar? ( virtual/fortran )"
> 
> However, with USE="foo -bar" this will first set the compiler
> for USE=foo, then reset it for USE=bar.

Ok, now both case and for will break immediately if fortran
compiler is found and passed tests.
 
The updated full v2 patch will be sent as a separate e-mail.

Best regards,
Andrew Savchenko


pgp2ox_htfNTs.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] fortran-2.eclass: support EAPI 7

2018-11-01 Thread Andrew Savchenko
Hi!

On Mon, 29 Oct 2018 23:52:31 +0100 Andreas K. Huettel wrote:
> > 
> > -inherit eutils toolchain-funcs
> > +inherit toolchain-funcs
> > 
> >  case ${EAPI:-0} in
> > -   4|5|6) EXPORT_FUNCTIONS pkg_setup ;;
> > +   4|5|6|7) EXPORT_FUNCTIONS pkg_setup ;;
> > *) die "EAPI=${EAPI} is not supported" ;;
> >  esac
> > 
> 
> ^ The disadvantage of this is that eutils inheritance then suddenly 
> disappears 
> for all ebuilds. And you don't know who assumed implicitly somewhere that 
> inheriting fortran-2 makes epatch available...
> 
> So how about still inheriting eutils for EAPI 4,5,6 and only dropping it for 
> EAPI 7 ?!

I agree, backward compatibility matters. Fixed in v2 patch.


Best regards,
Andrew Savchenko


pgplmIWTOpzDV.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] fortran-2.eclass: support EAPI 7

2018-11-01 Thread Andrew Savchenko
 debug-print-function ${FUNCNAME} "${@}"
 
local filebase=${T}/test-fortran
local fcomp=${1}
local fdia=${2}
local fcode=${filebase}.f${fdia}
local ret
 
[[ $# -lt 1 ]] && \
die "_fortran_compile_test() needs at least one argument"
 
[[ -f ${fcode} ]] || _fortran_write_testsuite
 
${fcomp} "${fcode}" -o "${fcode}.x" \
>> "${T}"/_fortran_compile_test.log 2>&1
ret=$?
 
rm -f "${fcode}.x"
return ${ret}
 }
 
 # @FUNCTION: _fortran-has-openmp
 # @RETURN: return code of the compiler
 # @INTERNAL
 # @DESCRIPTION:
 # See if the fortran supports OpenMP.
 _fortran-has-openmp() {
debug-print-function ${FUNCNAME} "${@}"
 
local flag
local filebase=${T}/test-fc-openmp
local fcode=${filebase}.f
-   local ret
local _fc=$(tc-getFC)
 
-   cat <<- EOF > "${fcode}"
+   cat <<- EOF > "${fcode}" || die
   call omp_get_num_threads
   end
EOF
 
for flag in -fopenmp -xopenmp -openmp -mp -omp -qsmp=omp; do
${_fc} ${flag} "${fcode}" -o "${fcode}.x" \
&>> "${T}"/_fortran_compile_test.log
-   ret=$?
-   (( ${ret} )) || break
+   [[ $? == 0 ]] && break
done
 
rm -f "${fcode}.x"
return ${ret}
 }
 
 # @FUNCTION: _fortran_die_msg
 # @INTERNAL
 # @DESCRIPTION:
 # Detailed description how to handle fortran support
 _fortran_die_msg() {
debug-print-function ${FUNCNAME} "${@}"
 
-   echo
+   eerror
eerror "Please install currently selected gcc version with USE=fortran."
eerror "If you intend to use a different compiler then gfortran, please"
eerror "set FC variable accordingly and take care that the necessary"
eerror "fortran dialects are supported."
-   echo
+   eerror
die "Currently no working fortran compiler is available (see 
${T}/_fortran_compile_test.log for information)"
 }
 
 # @FUNCTION: _fortran_test_function
 # @INTERNAL
 # @DESCRIPTION:
 # Internal test function for working fortran compiler.
 # It is called in fortran-2_pkg_setup.
 _fortran_test_function() {
debug-print-function ${FUNCNAME} "${@}"
 
local dialect
 
: ${F77:=$(tc-getFC)}
 
: ${FORTRAN_STANDARD:=77}
for dialect in ${FORTRAN_STANDARD}; do
case ${dialect} in
77) _fortran_compile_test $(tc-getF77) || \
_fortran_die_msg ;;
90|95) _fortran_compile_test $(tc-getFC) 90 || \
_fortran_die_msg ;;
2003) _fortran_compile_test $(tc-getFC) 03 || \
_fortran_die_msg ;;
2008) die "Future" ;;
*) die "${dialect} is not a Fortran dialect." ;;
esac
done
 
tc-export F77 FC
einfo "Using following Fortran compiler:"
einfo "  F77: ${F77}"
einfo "  FC:  ${FC}"
 
if [[ ${FORTRAN_NEED_OPENMP} == 1 ]]; then
if _fortran-has-openmp; then
einfo "${FC} has OPENMP support"
else
die "Please install current gcc with USE=openmp or set 
the FC variable to a compiler that supports OpenMP"
fi
fi
 }
 
 # @FUNCTION: _fortran-2_pkg_setup
 # @INTERNAL
 # @DESCRIPTION:
 # _The_ fortran-2_pkg_setup() code
 _fortran-2_pkg_setup() {
for _f_use in ${FORTRAN_NEEDED}; do
case ${_f_use} in
always)
-   _fortran_test_function && break
+   _fortran_test_function && break 2
;;
no)
einfo "Forcing fortran support off"
break
;;
*)
if use ${_f_use}; then
-   _fortran_test_function && break
+   _fortran_test_function && break 2
else
unset FC
unset F77
fi
;;
esac
done
 }
 
 
 # @FUNCTION: fortran-2_pkg_setup
 # @DESCRIPTION:
 # Setup functionality,
 # checks for a valid fortran compiler and optionally for its openmp support.
 fortran-2_pkg_setup() {
debug-print-function ${FUNCNAME} "${@}"
 
if [[ ${MERGE_TYPE} != binary ]]; then
_fortran-2_pkg_setup
fi
 }
 
 _FORTRAN_2_ECLASS=1
 fi


Best regards,
Andrew Savchenko


pgpuiK1GS9w0t.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] fortran-2.eclass: support EAPI 7

2018-10-28 Thread Andrew Savchenko
On Sun, 28 Oct 2018 19:29:28 +0100 Michał Górny wrote:
> On Sun, 2018-10-28 at 01:38 +0300, Andrew Savchenko wrote:
> > Hi all!
> > 
> > The only blocker for EAPI 7 update is eutils inheritance, but it
> > seems to be not used within the current eclass code, probably a
> > remnant from older days. So it is removed.
> > 
> > Looks like no other EAPI 7 specific changes needed.
> > 
> 
> Please use -U9 to include more context to the patches.
 
diff --git a/eclass/fortran-2.eclass b/eclass/fortran-2.eclass
index 820cbbcb49bd..1baf776e368a 100644
--- a/eclass/fortran-2.eclass
+++ b/eclass/fortran-2.eclass
@@ -1,285 +1,285 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: fortran-2.eclass
 # @MAINTAINER:
 # j...@gentoo.org
 # s...@gentoo.org
 # @AUTHOR:
 # Author Justin Lecher 
 # Test functions provided by Sebastien Fabbro and Kacper Kowalik
-# @SUPPORTED_EAPIS: 4 5 6
+# @SUPPORTED_EAPIS: 4 5 6 7
 # @BLURB: Simplify fortran compiler management
 # @DESCRIPTION:
 # If you need a fortran compiler, then you should be inheriting this eclass.
 # In case you only need optional support, please export FORTRAN_NEEDED before
 # inheriting the eclass.
 #
 # The eclass tests for working fortran compilers
 # and exports the variables FC and F77.
 # Optionally, it checks for extended capabilities based on
 # the variable options selected in the ebuild
 # The only phase function exported is fortran-2_pkg_setup.
 # @EXAMPLE:
 # FORTRAN_NEEDED="lapack fortran"
 #
 # inherit fortran-2
 #
 # FORTRAN_NEED_OPENMP=1
 
-inherit eutils toolchain-funcs
+inherit toolchain-funcs
 
 case ${EAPI:-0} in
-   4|5|6) EXPORT_FUNCTIONS pkg_setup ;;
+   4|5|6|7) EXPORT_FUNCTIONS pkg_setup ;;
*) die "EAPI=${EAPI} is not supported" ;;
 esac
 
 if [[ ! ${_FORTRAN_2_CLASS} ]]; then
 
 # @ECLASS-VARIABLE: FORTRAN_NEED_OPENMP
 # @DESCRIPTION:
 # Set to "1" in order to automatically have the eclass abort if the fortran
 # compiler lacks openmp support.
 : ${FORTRAN_NEED_OPENMP:=0}
 
 # @ECLASS-VARIABLE: FORTRAN_STANDARD
 # @DESCRIPTION:
 # Set this, if a special dialect needs to be supported.
 # Generally not needed as default is sufficient.
 #
 # Valid settings are any combination of: 77 90 95 2003
 : ${FORTRAN_STANDARD:=77}
 
 # @ECLASS-VARIABLE: FORTRAN_NEEDED
 # @DESCRIPTION:
 # If your package has an optional fortran support, set this variable
 # to the space separated list of USE triggering the fortran
 # dependency.
 #
 # e.g. FORTRAN_NEEDED=lapack would result in
 #
 # DEPEND="lapack? ( virtual/fortran )"
 #
 # If unset, we always depend on virtual/fortran.
 : ${FORTRAN_NEEDED:=always}
 
 for _f_use in ${FORTRAN_NEEDED}; do
case ${_f_use} in
always)
DEPEND+=" virtual/fortran"
RDEPEND+=" virtual/fortran"
break
;;
no)
break
;;
test)
DEPEND+=" ${_f_use}? ( virtual/fortran )"
;;
*)
DEPEND+=" ${_f_use}? ( virtual/fortran )"
RDEPEND+=" ${_f_use}? ( virtual/fortran )"
;;
esac
 done
 unset _f_use
 
 # @FUNCTION: fortran_int64_abi_fflags
 # @DESCRIPTION:
 # Return the Fortran compiler flag to enable 64 bit integers for
 # array indices
 # @CODE
 fortran_int64_abi_fflags() {
debug-print-function ${FUNCNAME} "${@}"
 
_FC=$(tc-getFC)
if [[ ${_FC} == *gfortran* ]]; then
echo "-fdefault-integer-8"
elif [[ ${_FC} == ifort ]]; then
echo "-integer-size 64"
else
die "Compiler flag for 64bit interger for ${_FC} unknown"
fi
 }
 
 # @FUNCTION: _fortran_write_testsuite
 # @INTERNAL
 # @DESCRIPTION:
 # writes fortran test code
 _fortran_write_testsuite() {
debug-print-function ${FUNCNAME} "${@}"
 
local filebase=${T}/test-fortran
 
# f77 code
cat <<- EOF > "${filebase}.f"
   end
EOF
 
# f90/95 code
cat <<- EOF > "${filebase}.f90"
end
EOF
 
# f2003 code
cat <<- EOF > "${filebase}.f03"
   procedure(), pointer :: p
   end
EOF
 }
 
 # @FUNCTION: _fortran_compile_test
 # @USAGE:  [dialect]
 # @INTERNAL
 # @DESCRIPTION:
 # Takes fortran compiler as first argument and dialect as second.
 # Checks whether the passed fortran compiler speaks the fortran dialect
 _fortran_compile_test() {
debug-print-function ${FUNCNAME} "

[gentoo-dev] [PATCH] fortran-2.eclass: support EAPI 7

2018-10-27 Thread Andrew Savchenko
Hi all!

The only blocker for EAPI 7 update is eutils inheritance, but it
seems to be not used within the current eclass code, probably a
remnant from older days. So it is removed.

Looks like no other EAPI 7 specific changes needed.

diff --git a/eclass/fortran-2.eclass b/eclass/fortran-2.eclass
index 820cbbcb49bd..1baf776e368a 100644
--- a/eclass/fortran-2.eclass
+++ b/eclass/fortran-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: fortran-2.eclass
@@ -8,7 +8,7 @@
 # @AUTHOR:
 # Author Justin Lecher 
 # Test functions provided by Sebastien Fabbro and Kacper Kowalik
-# @SUPPORTED_EAPIS: 4 5 6
+# @SUPPORTED_EAPIS: 4 5 6 7
 # @BLURB: Simplify fortran compiler management
 # @DESCRIPTION:
 # If you need a fortran compiler, then you should be inheriting
this eclass. @@ -27,10 +27,10 @@
 #
 # FORTRAN_NEED_OPENMP=1
 
-inherit eutils toolchain-funcs
+inherit toolchain-funcs
 
 case ${EAPI:-0} in
-   4|5|6) EXPORT_FUNCTIONS pkg_setup ;;
+   4|5|6|7) EXPORT_FUNCTIONS pkg_setup ;;
*) die "EAPI=${EAPI} is not supported" ;;
 esac
 

Best regards,
Andrew Savchenko


pgpF_Q63W15JG.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] [PATCH] appimage.eclass: new eclass

2018-10-07 Thread Andrew Savchenko
Hi!

On Sat,  6 Oct 2018 14:17:50 +0300 Mykyta Holubakha wrote:
> I'm proposing to add a new eclass: appimage.eclass, to facilitate
> extraction off AppImage bundles. The rationale is that some upstreams
> have migrated to distributing their proprietary software exclusively as
> AppImage bundles. (for instance dev-util/staruml-bin).
> 
> An example ebuild can be seen at https://git.io/fx3Mg
>
> I'd like to ask the following questions:
>
> 1. Can I put myself and proxy-maint under @MAINTAINER (or do I need to
> find a gentoo dev)?

Likely no. We have no such eclasses right now. Eclasses have more
strict requirements than ebuilds, e.g. they should not be changed
without a prior ML discussion except for project-specific eclasses.

> 2. Are we OK with executing AppImage bundles downloaded from the
> Internet (an alternative would be to implement a proper extractor
> program, which would unpack the images without executing them, and add
> it to DEPENDs).

This would be a considerable security risk, so no. You should use
some extractor. Looks like appimage carries filesystem inside with
some offset.

Best regards,
Andrew Savchenko


pgp8uIcWqqK7i.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc

2018-10-02 Thread Andrew Savchenko
On Mon, 1 Oct 2018 08:19:29 -0700 Zac Medico wrote:
> Hi all,
> 
> The ~arch version of portage hs a new QA check that reports installation
> of files outside of directories that have been whitelisted [1]. The
> current whitelist includes:
> 
> directories common to / and /usr
> 
> bin lib lib32 lib64 libx32 sbin
> 
> top level directories
> 
> boot dev etc opt srv usr var
> 
> /usr level directories
> 
> include libexec share src
> 
> /usr/share/doc level directories
> 
> /usr/share/doc/${PF}
> 
> The first bug report [2] is for qt-core, which installs documentation
> into  /usr/share/doc/${PN}-${PV} instead of /usr/share/doc/${PF} (${PF}
> includes ebuild revision such as -r1, -r2, and so on).

Sometimes documentation contains files used at run-time by the
application. Since application is usually not aware of Gentoo
specific revision numbers it is reasonable to install docs in
${PN}-${PV}. Such checks *must* be overrideable.

Best regards,
Andrew Savchenko


pgpfys2WFA_U2.pgp
Description: PGP signature


Re: [gentoo-dev] Changing policy about -Werror

2018-09-09 Thread Andrew Savchenko
On Sun, 9 Sep 2018 15:03:11 +0200 Thomas Deutschmann wrote:
> Hi,
> 
> I disagree. Either discuss to drop the entire policy about "-Werror" or
> don't but please do _not_ enter the game of differentiating between
> "normal" and something you call "security-orientated" packages.

You got me wrong. I'm not trying to build special rules for
security packages (since there is no margin between them and other
packages and you rightfully pointed out that any vulnerability may
play a role in a chained attack); they were just an example.

What I'm trying to do is to allow maintainers to keep -Werror if
they really want to do this, understand what they are doing and
have enough manpower to support this.

As can be seen from aforementioned bugs right now developer and
upstream support this to their best and yet QA team tries to
enforce -Werror drop using the brute force and ignoring active best
effort support. This should not happen.

Best regards,
Andrew Savchenko


pgp0NX1LMpgNP.pgp
Description: PGP signature


[gentoo-dev] Changing policy about -Werror

2018-09-09 Thread Andrew Savchenko
Hi!

Our current -Werror policy demands unconditional removal:
https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed

I think this is wrong, see bugs 665464, 665538 for a recent
discussion why.

My point is that in *most* cases -Werror indeed should be removed,
because upstream rarely can keep up with all possible configure,
*FLAGS, compiler versions and arch combinations. But! In some cases
— especially for security oriented software — this flag may be
pertain and may be kept at maintainer's discretion.

The rationale is that -Werror usually points to dangerous
situations like uninitialized variables, pointer type mismatch or
implicit function declaration (and much more) which may lead to
serious security implications.

So, if maintainer has enough manpower to support this flag, we
should allow to keep it. Of course if it will cause long-standing
troubles (e.g. bugs opened for a long time) QA should have power to
remove it or demand its removal.

So my proposal is:

1) Deprecate QA policy with unconditional demand of -Werror removal.
2) Add to devmanual's chapter on -Werror an exception clause about
security-oriented software and maintainer's right to make final
decision.

Best regards,
Andrew Savchenko


pgpjt0_Y4nNob.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites: www-plugins/gnash

2018-08-29 Thread Andrew Savchenko
On Wed, 29 Aug 2018 03:20:31 +0200 Chí-Thanh Christopher Nguyễn
wrote:
> # Chí-Thanh Christopher Nguyễn  (29 Aug 2015)
> # Masked for removal in 30 days. Multiple build failures. Upstream inactive.
> # (bugs #321017, #581284, #588692, #602786, #649006, #654140)
> www-plugins/gnash
 
Is there any replacement available? AFAIK no, at least among free
software. And there still many sites which require flash to work.

So maybe mask it, but not remove?

Best regards,
Andrew Savchenko


pgpgNyL34Tjrr.pgp
Description: PGP signature


Re: [gentoo-dev] Help with category for Authenticator

2018-08-28 Thread Andrew Savchenko
On Tue, 28 Aug 2018 09:32:29 -0500 Alexander Trotsenko wrote:
> Hello, guys!
> 
> I tried asking this question in #gentoo-proxy-maint IRC and I was told I
> should venture for gentoo-dev mailing list.
> 
> So I introduced a new package into Gentoo, Authenticator
> (https://github.com/bilelmoussaoui/Authenticator). I placed it under
> gnome-extra. However, shortly after the commit, gnome-extra guy said it
> does not belong there and I am supposed it to move somewhere else. There
> is a bug that touches this subject https://bugs.gentoo.org/663820.
> 
> I currently consider to move it to app-crypt. Some folks also suggested
> net-misc as a reasonable destination. I wonder if I could contact
> "maintainers" so to say of those categories to make sure they are
> willing to accept authenticator within their category.
> 
> What's the best way to handle this situation? Also, if somebody wants to
> suggest yet another category, speak up!

I suggest the system-auth category.

Why? It is always good to look where similar applications belong.
Authenticator is basicall 2FA/OATH GUI, and oath-toolkit is in
system-auth, most yubikey stuff is there as well.

And now look in sys-auth/metadata.xml:

The sys-auth category contains applications and libraries to support
authentication and authorization facilities.
Here belongs PAM modules, NSS modules and login apps.

Authenticator fits here perfectly as an application to support
authentication and authorization facilities.

Best regards,
Andrew Savchenko


pgpDIGc0wsY_P.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

2018-08-26 Thread Andrew Savchenko
On Sun, 26 Aug 2018 00:28:16 -0700 Zac Medico wrote:
> On 08/25/2018 07:11 PM, Andrew Savchenko wrote:
> > On Sat, 25 Aug 2018 14:24:02 -0400 Mike Gilbert wrote:
> >> On Sat, Aug 25, 2018 at 1:41 AM Andrew Savchenko  
> >> wrote:
> >>>
> >>> On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote:
> >>>> ---
> >>>>  general-concepts/dependencies/text.xml | 38 ++
> >>>>  1 file changed, 38 insertions(+)
> >>>>
> >>>> diff --git a/general-concepts/dependencies/text.xml 
> >>>> b/general-concepts/dependencies/text.xml
> >>>> index 2f10380..64be9dc 100644
> >>>> --- a/general-concepts/dependencies/text.xml
> >>>> +++ b/general-concepts/dependencies/text.xml
> >>>> @@ -578,6 +578,44 @@ valid.
> >>>>  
> >>>>  
> >>>>
> >>>> +
> >>>> +Test Dependencies
> >>>> +
> >>>> +
> >>>> +
> >>>> +Packages often have optional dependencies that are needed only when 
> >>>> running
> >>>> +tests. These should be specified in DEPEND behind a USE flag. Often, the
> >>>> +'test' USE flag is used for this purpose.
> >>>> +
> >>>> +
> >>>> +
> >>>> +Since testing will likely fail when test dependencies are not 
> >>>> installed, the
> >>>> +test phase should be disabled in this case. This may be accomplished 
> >>>> via USE
> >>>> +conditionals in the RESTRICT variable.
> >>>> +
> >>>> +
> >>>> +
> >>>> +If other optional features must be enabled/disabled when testing, 
> >>>> REQUIRED_USE
> >>>> +may be set to express this.
> >>>> +
> >>>> +
> >>>> +
> >>>> +# Define some USE flags
> >>>> +IUSE="debug test"
> >>>> +
> >>>> +# Disable test phase when test USE flag is disabled
> >>>> +RESTRICT="!test? ( test )"
> >>>
> >>> I do not understand why we need this useless code. If test USE flag
> >>> is disabled, tests must be disabled as well. It is PM's job and
> >>> there is no need to put this obvious stuff into each ebuild with
> >>> tests and extra deps. I see no reason to support running src_test()
> >>> with USE="-test".
> >>
> >> PMS does not specify that behavior (skipping src_test with USE=-test).
> >> It is better to define the requrement explicitly rather than relying
> >> on a Portage-specific behavior.
> > 
> > Then PMS should be fixed. Putting useless code in thousands
> > of ebuilds due to bureaucratic reasons is ridiculous. Having strict
> > conformance to the PMS is good, but common sense should still be
> > considered.
> 
> Since PMS doesn't specify the behavior of FEATURES, I suppose we could
> make FEATURES=test imply RESTRICT="!test? ( test )". Would there be any
> drawbacks to that?

IMO no. This is what everyone expects from the test feature.

Best regards,
Andrew Savchenko


pgpy8U5vziMny.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] New global USE flag: gtk-doc

2018-08-25 Thread Andrew Savchenko
On Fri, 24 Aug 2018 23:06:46 +0300 Mart Raudsepp wrote:
> USE=doc has a very overloaded meaning.
> Meson doesn't ship pre-generated gtk-docs like autotools did, thus
> developers writing GLib/GTK+ apps may want to keep them around, as
> libraries move from autotools to meson. gtk-doc is integrated into
> various IDEs and standalone devhelp viewer, giving a concrete case when
> one might want to globally enable this (if using those IDEs until they
> don't have online gtk-doc support that's still in the works, offline
> developer docs, or matching system versions docs on purpose).
> Per-package USE=doc is rather inconvenient to manage.
> 
> Suggested description for global gtk-doc USE:
> Build and install gtk-doc based developer documentation
> 
> Longer version idea:
> Build and install gtk-doc based developer documentation for dev-
> util/devhelp, IDE and offline use
> 
> 
> As the "Build" in the description suggests, this is only for when a
> generation is needed. In practice this means that it shouldn't be used
> for autotools based builds from tarballs, where the gtk-doc is already
> shipped - for those you just want a dev-util/gtk-doc-am build dep,
> which will make gtkdoc-rebase available that the standard gtk-doc
> autotools rules call to make the pre-generated docs pretty much equal
> to what you'd get from regenerating (mainly local offline links). In
> those aforementioned autotools cases, it's often questionable to have a
> USE flag (doc) at all for this when using proper tarballs.
> 
> Most GNOME libraries have converted to using meson, thus building them
> is necessary to keep local developer docs available and thus keep IDE
> integration useful. Just always building gtk-doc would be distasteful
> to some, hence this global USE flag proposal. There will be dozens of
> consumers as I bump libraries for GNOME 3.26 and even more so 3.28 and
> 3.30 soon enough afterwards. Some are already there (including some not
> from GNOME), which currently use USE=doc for this.
> Instead of supporting disted tarballs with meson, they plan to do
> aforementioned online docs support for the API docs integrations, but
> I haven't heard about any progress on that, plus offline use use case
> will remain anyways.

Looks like we have a larger issue here. USE=doc covers all types of
documentation outside of man, info pages and maybe some small text
files. Such additional documentation often includes API reference
manual and people may want to have it if they are using it during
development or may want to disable it, but keep user-level
documentation, because API docs often take quite some time to
build. Such cases cover html docs, doxygen docs, gtk-doc and so on.

So what about some new flag for API reference and other huge
development documentation? E.g. USE="apidoc"?

Best regards,
Andrew Savchenko


pgpAPSauwiGKm.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

2018-08-25 Thread Andrew Savchenko
On Sat, 25 Aug 2018 14:24:02 -0400 Mike Gilbert wrote:
> On Sat, Aug 25, 2018 at 1:41 AM Andrew Savchenko  wrote:
> >
> > On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote:
> > > ---
> > >  general-concepts/dependencies/text.xml | 38 ++
> > >  1 file changed, 38 insertions(+)
> > >
> > > diff --git a/general-concepts/dependencies/text.xml 
> > > b/general-concepts/dependencies/text.xml
> > > index 2f10380..64be9dc 100644
> > > --- a/general-concepts/dependencies/text.xml
> > > +++ b/general-concepts/dependencies/text.xml
> > > @@ -578,6 +578,44 @@ valid.
> > >  
> > >  
> > >
> > > +
> > > +Test Dependencies
> > > +
> > > +
> > > +
> > > +Packages often have optional dependencies that are needed only when 
> > > running
> > > +tests. These should be specified in DEPEND behind a USE flag. Often, the
> > > +'test' USE flag is used for this purpose.
> > > +
> > > +
> > > +
> > > +Since testing will likely fail when test dependencies are not installed, 
> > > the
> > > +test phase should be disabled in this case. This may be accomplished via 
> > > USE
> > > +conditionals in the RESTRICT variable.
> > > +
> > > +
> > > +
> > > +If other optional features must be enabled/disabled when testing, 
> > > REQUIRED_USE
> > > +may be set to express this.
> > > +
> > > +
> > > +
> > > +# Define some USE flags
> > > +IUSE="debug test"
> > > +
> > > +# Disable test phase when test USE flag is disabled
> > > +RESTRICT="!test? ( test )"
> >
> > I do not understand why we need this useless code. If test USE flag
> > is disabled, tests must be disabled as well. It is PM's job and
> > there is no need to put this obvious stuff into each ebuild with
> > tests and extra deps. I see no reason to support running src_test()
> > with USE="-test".
> 
> PMS does not specify that behavior (skipping src_test with USE=-test).
> It is better to define the requrement explicitly rather than relying
> on a Portage-specific behavior.

Then PMS should be fixed. Putting useless code in thousands
of ebuilds due to bureaucratic reasons is ridiculous. Having strict
conformance to the PMS is good, but common sense should still be
considered.

Best regards,
Andrew Savchenko


pgpoAHQZktz8T.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo i486 support

2018-08-25 Thread Andrew Savchenko
Hi!

On Wed, 22 Aug 2018 09:08:06 -0400 Rich Freeman wrote:
> On Wed, Aug 22, 2018 at 8:26 AM Ben Kohler  wrote:
> >
> > 1) Adjust x86 profile defaults to drop the problematic -march=i686.
> > This would be more in line with amd64 profiles (et al), which set no
> > -march value so it can run on any hardware for this arch.
> >
> 
> My knee-jerk reaction was that this is a bad idea, but after a bit of
> thought there are some arguments in favor of this:
> 
> First, the argument against: i386 is VERY old.  Most distros moved
> their defaults to i686 because it had significant improvements, and
> i686 was still mainstream but i386 was ancient.  In contrast with
> amd64 the entire architecture is fairly new and the baseline doesn't
> suffer from many of the issues i386 suffers compared to i686.  This is
> a really short synopsis - if you go to any distro list archive you can
> find long passionate arguments from ~10 years ago that elaborated on
> this.  In that sense, going back to i386 is turning back the clock.
> 
> HOWEVER, I think there is an argument for i386 that wasn't so valid
> back then.  x86 in general is starting to look a bit like i386.  What
> are the main use cases for it in this day and age?  I don't use x86,
> so I'm not the best person to answer that.  However, I'd broadly split
> it into two categories (mostly by tautology):
> 
> 1.  Museum hardware.  People have systems that are running simply
> BECAUSE they are old, not because they are cost-effective/etc.  I'm
> not sure I'd even lump used hardware into this category any longer, as
> I'm sure there are plenty of i686+ used PCs at rock-bottom prices
> already out there, and maintaining pre-Y2K hardware is going to be
> fairly painful.  For this use case i386 as the baseline makes a LOT of
> sense.
> 
> 2.  Non-museum hardware.  People have x86 hardware because it is the
> most cost-effective solution for a task, and not merely because it is
> old.  IMO for this use case i686 makes a lot more sense as a baseline.
> However, I'm honestly not sure in this day and age what these use
> cases even are, unless it is something you can buy for $10 at a flea
> market.  Even if you're talking about a container running one
> application that only needs 500kB of RAM, is there really that much
> benefit to not building it for amd64?

As active x86 hardware user I can add:

3. Security. CPUs without speculative execution and L3 cache are
much more secure by design. Thanks to the virtues of Gentoo
(highest possible code optimization and ability to USE light
versions of applications) such hardware (e.g. 32bit Atoms) is still
usable quite fine.

Best regards,
Andrew Savchenko


pgpcE7BQXwWmm.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

2018-08-24 Thread Andrew Savchenko
On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote:
> ---
>  general-concepts/dependencies/text.xml | 38 ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/general-concepts/dependencies/text.xml 
> b/general-concepts/dependencies/text.xml
> index 2f10380..64be9dc 100644
> --- a/general-concepts/dependencies/text.xml
> +++ b/general-concepts/dependencies/text.xml
> @@ -578,6 +578,44 @@ valid.
>  
>  
>  
> +
> +Test Dependencies
> +
> +
> +
> +Packages often have optional dependencies that are needed only when running
> +tests. These should be specified in DEPEND behind a USE flag. Often, the
> +'test' USE flag is used for this purpose.
> +
> +
> +
> +Since testing will likely fail when test dependencies are not installed, the
> +test phase should be disabled in this case. This may be accomplished via USE
> +conditionals in the RESTRICT variable.
> +
> +
> +
> +If other optional features must be enabled/disabled when testing, 
> REQUIRED_USE
> +may be set to express this.
> +
> +
> +
> +# Define some USE flags
> +IUSE="debug test"
> +
> +# Disable test phase when test USE flag is disabled
> +RESTRICT="!test? ( test )"

I do not understand why we need this useless code. If test USE flag
is disabled, tests must be disabled as well. It is PM's job and
there is no need to put this obvious stuff into each ebuild with
tests and extra deps. I see no reason to support running src_test()
with USE="-test".

> +# Running tests requires 'foo' to be installed
> +DEPEND="test? ( dev-util/foo )"
> +
> +# Require debug support when tests are enabled
> +REQUIRED_USE="test? ( debug )"
> +
> +
> +
> +
> +
>  
>  
>  


Best regards,
Andrew Savchenko


pgpQJ7D4TfKlS.pgp
Description: PGP signature


Re: [gentoo-dev] Experimental 2-step authentication support on dev.gentoo.org

2018-08-09 Thread Andrew Savchenko
On Thu, 09 Aug 2018 10:27:35 +0200 Michał Górny wrote:
> Hi, everyone.
> 
> Just a short notice: we've enabled experimental support for 2-step
> authentication when logging in to woodpecker via SSH.  For more details,
> see [1].
> 
> TL;DR: as a technical limitation, some SSH clients may start asking you
> for a password.  Using any non-empty string will work.

When authenticating as usual (using encrypted ssh key) I see
"Authenticated with partial success.", auth itself is OK.

Could you please disable this ambiguous message?

Best regards,
Andrew Savchenko


pgpfNZSZE32Bl.pgp
Description: PGP signature


Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

2018-08-04 Thread Andrew Savchenko
Hi,

On Sat, 4 Aug 2018 07:29:47 -0700 Hanno Böck wrote:
> > Symmetric cryptography is quite conservative and it took years and
> > even decades for algorithms and their implementations to become
> > trusted, so there is nothing wrong in using good old verified
> > software.
> 
> When it comes to cipher modes the fact that people use decades old
> modes is a problem. See efail for a prominent example, but there
> are many less prominent ones.
> 
> Look at the mcrypt webpage:
> http://mcrypt.sourceforge.net/
> 
> Modes of Operation:
> 
> CBC
> CFB
> CTR
> ECB
> OFB
> NCFB
> 
> That is a mixture of very insecure (ECB), insecure in most situations
> (all others) and totally obscure modes. It doesn't include any
> authenticated encryption modes, which in most situations is what you
> want to use.

I want to use mcrypt for local encryption only, therefore I don't
really care about MACs. In my use cases modification tampering is
easy to detect by other means.

ECB is indeed unsafe and must be avoided (hey, openssl supports ECB
as well, let's ban it!).

CBC is better, but vulnerable to PODDLE, so I agree on avoiding it
as well.

As for CTR, (N)CFB, (N)OFB there is nothing obscure about them:
they are known for decades and are well studied. There are no
direct attacks on these modes known aside from detectable tampering
possibility.

Best regards,
Andrew Savchenko


pgpOpfRZo6zw5.pgp
Description: PGP signature


Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

2018-08-04 Thread Andrew Savchenko
On Sat, 4 Aug 2018 13:05:56 -0500 Marty E. Plummer wrote:
[...]
> It seems that every last person commenting on this is talking mcrypt,
> not mhash, which is what I mentioned in the first place. As far as I can
> tell, these are entirely differnt projects which just happen to have a
> similar name.

Yes, they are. But it this very case I'm interested in mcrypt
status, not mhash, that's why I changed the subject field of this
discussion. 

Best regards,
Andrew Savchenko


pgpZBs6CP4JXU.pgp
Description: PGP signature


Re: [gentoo-dev] Re: mcrypt status

2018-08-04 Thread Andrew Savchenko
On Sat, 4 Aug 2018 09:51:14 + (UTC) Martin Vaeth wrote:
> Andrew Savchenko  wrote:
> >
> > Actually for local symmetric encryption this is the best tool I
> > know.
> 
> What is the advantage over gpg --symmetric?

1) mcrypt has wider range of algorithms, including gost which I
need.
2) gpg-agent sometimes causes too much trouble (by being enforced
in gpg2) and I like it more to enter passphares without any agents.
xterm can grab screen and that is sufficient for my needs.

Other than that gpg -s in nice and good tool.

Best regards,
Andrew Savchenko


pgpwFLuH6LfnQ.pgp
Description: PGP signature


mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

2018-08-04 Thread Andrew Savchenko
On Mon, 25 Jun 2018 07:59:47 +0200 Hanno Böck wrote:
> On Fri, 22 Jun 2018 21:50:50 -0500
> "Marty E. Plummer"  wrote:
> 
> > So, as you may be aware I've been doing some work on moving bzip2 to
> > an autotools based build. Recently I've ran into app-crypt/mhash,
> > which is in a semi-abandoned state (talking with the maintainer on
> > twitter atm), and I was thinking it may be a good idea to set up a
> > project for keeping these semi-abandoned and really-abandoned
> > libraries and projects up to date and such.
> 
> This is a common problem, however if you want to make this reasonable
> you wouldn't make it a gentoo thing, but a cross-distro effort. The
> idea has been tossed around a lot, but noone yet started implementing
> it.
> 
> However keeping things alive may not always be the right option.
> There's a reason mcrypt is abandoned. It's an ancient crypto library,
> crypto is moving forward, there are better options.

Do you have any evidence that mcrypt should not be used?

Symmetric cryptography is quite conservative and it took years and
even decades for algorithms and their implementations to become
trusted, so there is nothing wrong in using good old verified
software.

Actually for local symmetric encryption this is the best tool I
know.

Best regards,
Andrew Savchenko


pgpwPymO8y5c2.pgp
Description: PGP signature


Re: [gentoo-dev] Looking for Perl help verifying old Gentoo elections

2018-08-03 Thread Andrew Savchenko
On Fri, 03 Aug 2018 17:00:51 +0200 Michał Górny wrote:
> Hi, everyone.
> 
> Inspired by Robin, I've started working on scripts to verify old Gentoo
> election results.  Since our election mechanism is apparently the same
> as used by Debian, it seemed an obvious choice to use the Debian tooling
> (devotee) to verify our results.

As far as I know it is not the same. While we both use Condorcet
method, Gentoo allows several nominees with the same rank, while
Debian does not.

Best regards,
Andrew Savchenko


pgpKGpagYe9H7.pgp
Description: PGP signature


Re: [gentoo-dev] Add rust eclass to support multi-target compilation

2018-07-30 Thread Andrew Savchenko
Hi!

On Mon, 30 Jul 2018 17:00:20 +0200 gibix wrote:
> Hello,
> 
> I opened a PR here: https://github.com/gentoo/gentoo/pull/9388
> 
> Here a copy of the message:
> 
> # add support for rust multi-target
> 
> - add rust.eclass (with rust-utils.class) to support rust multi-target with
>   multibuild
> - modify cargo.class to support rust multi-target
> - change dev-lang/rust slot system
> 
> This will allows projects like rustfmt, clippy, bindgen that need runtime
> linking with the proper rust version to work correctly. Beyond this while
> rust is getting older as project we will see more projects that will
> require a specific rust version for compilation.
> 
> This PR replaces the need for rustup in gentoo for toolchain handling and
> components.
> 
> requires:
> - [features in
>   
> cargo-ebuild](https://github.com/cardoe/cargo-ebuild/pull/14/commits/1aefd302f9430c0b628923da23e2a8d74b83d1ec)
> - [binaries support into
>   eselect-rust](https://github.com/jauhien/eselect-rust/pull/4)
> 
> see first discussion on
> [gentoo-rust](https://github.com/gentoo/gentoo-rust/pull/362)

If you are submitting code to the main tree, please submit all
requirements to the tree first.

Your PR brokes tree:
https://github.com/gentoo/gentoo/pull/9388#issuecomment-408914903

Please fix these issues as well, for both QA and CI checks. (These
problems may be a result of §1 (not yet submitted changes to the
tree).

It would be easier if your will split your improvements into series
of atomic changes and submit them individually for review.

Best regards,
Andrew Savchenko


pgpyqcZzV6va0.pgp
Description: PGP signature


Re: [gentoo-dev] rfc: [QA] Ban policy introduction

2018-07-29 Thread Andrew Savchenko
On Sun, 29 Jul 2018 16:47:47 +0900 Alice Ferrazzi wrote:
> Sent from my phone. Please excuse my brevity.
> 
> On Sun, 29 Jul 2018, 16:39 Fabian Groffen,  wrote:
> 
> > Completely agreeing with Sergei, with some additional suggestions:
> >
> > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote:
> > > On Sun, 29 Jul 2018 00:40:18 +0300
> > > Mikle Kolyada  wrote:
> > >
> > > > Hello,
> > > >
> > > > The Gentoo QA team would like to introduce the following policy that
> > > > would be applied to individuals breaking the state and quality of the
> > > > main gentoo.git tree
> > > >
> > > > ( as we do not have this strictly documented yet):
> > > >
> > > > 
> > > >
> > > > If recommended
> > >
> > > It's not called "recommended" but "enforced".
> >
> > I agree.  If you put penalties on these, they become hard rules.  I
> > think that change should be discussed by the council perhaps?

+1. Also please provide some tool for developers to check for
compliance to these rules, e.g. repoman full must perform all these
checks.

If developers have no way to verify correctness of the code, they
can't be held responsible for accidental violation of the rules.

> > > > the standard QA
> > > > procedure is:
> > > >
> > > > 1.) Two warnings granted by QA team, after two independent breakages
> > > > 2.) Revoking the commit access for 14 days
> > > >
> > > > These violations will be evaluated individually by all QA team members.
> > > > Warnings can be revoked, if during 6 months period a developer makes at
> > > > least 20 non trivial changes not producing more breakages.

Why 6 months period? Why time frame at all? 20 good commits sounds
OK. If you want time frame, then you should set autoexpire of
warning as well.

What is the definition of non-trivial change? There will be commits
which may be seen as trivial by one person (e.g. because it is
one-liner) and as non-trivial by another (e.g. because such commit
fixes serious bug).

> if you want to enforce rules, would be productive to also have extensive
> documentation on how to avoid to make such problems.
> Better would be to invest more time in something like the breckage checker
> script, similar at what mgorny is doing, than adding more ways to block
> developers contributions.
> 
> thanks,
> Alice

Best regards,
Andrew Savchenko


pgpmyxUP15S3S.pgp
Description: PGP signature


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-26 Thread Andrew Savchenko
Hi!

On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote:
> I'd like to propose adding USE=udev to our linux profiles (in 
> profiles/default/linux/make.defaults probably).  This flag is already 
> enabled on desktop profiles but it also affects quite a few packages 
> used on non-desktop linux systems.
> 
> This flag provides useful functionality that most linux users will want. 
>   I'm a bit surprised that we still don't have it in all linux profiles, 
> but I think we've worked around this in the past by adding IUSE=+udev to 
> quite a few of those packages (33 packages, 116 ebuilds, by my count).
> 
> This missing flag came to my attention again on bug 661584 where lvm2 
> has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users 
> have a bit of a mismatch between the 2 and get ugly errors on cryptsetup.
> 
> Since this flag only affects linux, I think it makes more sense to set 
> it in linux profiles than to use IUSE defaults.
> 
> Any objections to this idea?

A user had contacted me with his input from the HPC world, I'm
redirecting his e-mail here. James is whitelisted now so he can
further participate in this discussion himself if necessary.

As an HPC user of Gentoo I agree that minimal and highly optimized
Gentoo setups are indeed very useful and must stay that way.

Begin forwarded message:

Date: Wed, 25 Jul 2018 13:31:59 -0400
From: james 
To: birc...@gentoo.org
Subject: udev's future


Hello Andrew,


Sorry, I do not have direct posting ability to gentoo-dev, so in
hopes of finding a dev-sponsor, I hope you will paraphrase this
email to you for the sake of preventing 'dev as a default' or base
setting of any sort.


My research and testing for  new HPC configurations, has systemd
and udev at the heart of codes to avoid to optimize the
heterogeneous nature of the clusters I'm building. In fact my
development work, although delayed due to transient-illness, is
more of a gentoo-centric convergence of embedded-gentoo, minimal
(server) gentoo, gentoo-hpc clusters and unikernels. As far as
performance and security are concerned  'less' is always better.
Those codes and ebuild that are desired are to added in a higher
level; hoping to continue the leverage the portage tree of
applications, only as dynamically required.


Avoidance of setting udev or in any form mandating any part of
systemd will have dire consequences and cost me months, if not
years  to find a way to 'totally undo' the ravages of udev.
Minimized kernels are also fundamental to my loosely-coupled
(gentoo) HPC development. Even tiny Rtos based embedded linux
systems are in the process of being included in a loosely-coupled
gentoo centric heterogeneous HPC cluster.  I would 'beg' against
making udev primary under any circumstance.


Gentoo has a unique and powerful position, just for it's position of
choice and minimizational features; After 15 years, I'd hate to have
to work in another distro, as gentoo has served me extraordinarily
well over the decades.


sincerely,
James Horton, PE

Best regards,
Andrew Savchenko


pgppp_tVASKom.pgp
Description: PGP signature


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-25 Thread Andrew Savchenko
On Tue, 24 Jul 2018 12:14:55 -0400 Rich Freeman wrote:
> On Tue, Jul 24, 2018 at 12:06 PM Michael Orlitzky  wrote:
> >
> > On 07/24/2018 11:39 AM, Mike Gilbert wrote:
> > >
> > > You can run any system without udev, but you need to be very careful
> > > about what Linux features you utilize and how you have the system
> > > configured.
> > >
> > > Most Linux servers out in the wild are running udev; your
> > > configuration is an exception to the common case.
> > >
> >
> > Gentoo users are Gentoo users because Gentoo is easy to customize.
> 
> I don't believe anybody suggested making Gentoo harder to customize.
> This is just about setting reasonable defaults.

Adding udev to the base profile will make customization much harder
for people unwilling to use udev. This is the problem.

> You can run a server without bash, openrc, sysvinit, or glibc.  Should
> these also be removed from the base profile?

Best regards,
Andrew Savchenko


pgpOD7NDol1Xw.pgp
Description: PGP signature


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-24 Thread Andrew Savchenko
On Mon, 23 Jul 2018 11:03:34 -0400 Mike Gilbert wrote:
> On Mon, Jul 23, 2018 at 1:47 AM Andreas K. Huettel  
> wrote:
> >
> > Am Donnerstag, 19. Juli 2018, 23:51:17 CEST schrieb Ben Kohler:
> > > Hello,
> > >
> > > I'd like to propose adding USE=udev to our linux profiles (in
> > > profiles/default/linux/make.defaults probably).  This flag is already
> > > enabled on desktop profiles but it also affects quite a few packages
> > >
> > > Any objections to this idea?
> >
> > We removed the dedicated "server profiles" and told everyone
> > "Don't ever use -*"; if you want to have a sane minimal set of features use
> > the base profile as e.g. default/linux/amd64/17.0".
> >
> > If with USE=udev this profile still fulfills the definition of "sane minimal
> > set of features", then it's fine.
> >
> > (Keep in mind, we have all sorts of people out there running gentoo not only
> > on desktops or beefy servers.)
> >
> > Otherwise it should stay in desktop profile.
> 
> USE="udev" is a sane default for anything that will be running on real
> or emulated hardware. It might not be necessary for containers, which
> don't do any hardware management.

I do not agree with you. I have perfectly fine running
Gentoo-based servers running without udev and so many other people.
udev in desktop profile is just fine with me, on servers it is not
needed in many cases. 


Best regards,
Andrew Savchenko


pgpickXtzqojh.pgp
Description: PGP signature


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Andrew Savchenko
On Thu, 19 Jul 2018 23:51:05 -0400 Aaron Bauman wrote:
> You are the minimalist... Not the rest.  Provide a reasonable scenario please.

Such setup is quite simple: secure server or container usually for
a single task with minimal setup of packages and USE flags to
reduce attack surface.

Best regards,
Andrew Savchenko


pgpleYuSQ46h1.pgp
Description: PGP signature


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Andrew Savchenko
On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote:
> Hello,
> 
> I'd like to propose adding USE=udev to our linux profiles (in 
> profiles/default/linux/make.defaults probably).  This flag is already 
> enabled on desktop profiles but it also affects quite a few packages 
> used on non-desktop linux systems.
> 
> This flag provides useful functionality that most linux users will want. 
>   I'm a bit surprised that we still don't have it in all linux profiles, 
> but I think we've worked around this in the past by adding IUSE=+udev to 
> quite a few of those packages (33 packages, 116 ebuilds, by my count).
> 
> This missing flag came to my attention again on bug 661584 where lvm2 
> has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users 
> have a bit of a mismatch between the 2 and get ugly errors on cryptsetup.
> 
> Since this flag only affects linux, I think it makes more sense to set 
> it in linux profiles than to use IUSE defaults.
> 
> Any objections to this idea?

I have server setups with udev disabled for most packages. So udev
enabled by default will create maintenance problems. While I'm
perfectly fine with udev enabled by default on desktops, it should
not be forced on minimalistic setups like servers or containers.

Best regards,
Andrew Savchenko


pgpKn16FFnEw6.pgp
Description: PGP signature


Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)

2017-12-11 Thread Andrew Savchenko
On Fri, 08 Dec 2017 21:22:32 +0100 Andreas K. Huettel wrote:
> Am Donnerstag, 7. Dezember 2017, 19:06:36 CET schrieb William L. Thomson Jr.:
> > 
> > The day everyone wanted has come, after this message. I will
> > unsubscribe not to return. You all won in 2008, and again in 2017.
> > Though this time I will not be back. I tried more than most anyone else
> > would for a very long time. Gentoo wins I lose, I am fine with that.
> > 
> > Please do not contact me off list in IRC or at all. I am done with the
> > Gentoo community!
> 
> 
> Independent of whether William now unsubscribed or not, he's now enjoying a 
> lengthy (1 year until review) vacation from all Gentoo communication channels.
> 

Thank you very much. Mail list are becoming readable again (: 

Best regards,
Andrew Savchenko


pgpn21xIVRZHc.pgp
Description: PGP signature


Re: [gentoo-dev] [openrc] [systemd] make `service` common for both OpenRC and SystemD (like Debian/Ubuntu/whatever did)

2017-09-17 Thread Andrew Savchenko
On Sun, 17 Sep 2017 12:05:07 +0200 Michał Górny wrote:
> W dniu nie, 17.09.2017 o godzinie 12∶12 +0300, użytkownik Andrew
> Savchenko napisał:
> > On Sun, 17 Sep 2017 02:56:08 +0700 Vadim A. Misbakh-Soloviov wrote:
> > > Hi there!
> > > 
> > > Every time I switch from mastering service on my work (Ubuntu-powered) to 
> > > my 
> > > own server farm (Gentoo powered) I'm going a bit frustrated: Ubuntu (with 
> > > all 
> > > my hate to many other things in it) has nice user-friendly way of 
> > > managing 
> > > services: you can freely call any of `service  action` 
> > > irrelevant 
> > > to which init-system is currently in use. Will it be systemd, or 
> > > (whatever 
> > > there is alternative there). `service` wrapper will detect it anyway and 
> > > will 
> > > do the proper things (forward it to either systemd or another service 
> > > manager).
> > > 
> > > I'd like to suggest to remove `service` widget from openrc and make it 
> > > the 
> > > part of (which package? baselayout?)? Here is a pseudocode of how I see 
> > > it:
> > > 
> > > ```
> > > servicename=${1}
> > > action=${2}
> > > 
> > > if in_systemd; then
> > >   systemctl "${action}" "${servicename}"
> > > else
> > >   rc-service "${servicename}" "${action}"
> > > fi
> > > ```
> > > 
> > > Well, actually, there may be some more logic (for example, instance units 
> > > (`unit@instance` in `systemd` vs `unit.instance` in openrc), "enable" 
> > > action 
> > > (forward it to `rc-update add` for `openrc`, probably) and maybe some 
> > > more.
> > > But anyway, the conception is something like that.
> > > 
> > > 
> > > What do you think about that?
> > 
> > https://xkcd.com/927/
> > 
> > We will create even more confusion for Gentoo users with one more
> > tool to do the same stuff.
> > 
> > Of course you are free to implement some separate wrapper package,
> > but it must be completely optional, since some users will have no
> > use for it including myself.
> > 
> > Really, unifying distributions is futile. We will have either the
> > same and only distribution (to rule them all) or an attempt will
> > fail. The same way you can try to unify emerge and apt tools via
> > some wrapper manager.
> 
> Fun fact: systemd was created to unify distributions in one init system.
 
Exactly. This case is perfectly covered by https://xkcd.com/927/ :)

Best regards,
Andrew Savchenko


pgpbfEazXDncT.pgp
Description: PGP signature


Re: [gentoo-dev] [openrc] [systemd] make `service` common for both OpenRC and SystemD (like Debian/Ubuntu/whatever did)

2017-09-17 Thread Andrew Savchenko
On Sun, 17 Sep 2017 02:56:08 +0700 Vadim A. Misbakh-Soloviov wrote:
> Hi there!
> 
> Every time I switch from mastering service on my work (Ubuntu-powered) to my 
> own server farm (Gentoo powered) I'm going a bit frustrated: Ubuntu (with all 
> my hate to many other things in it) has nice user-friendly way of managing 
> services: you can freely call any of `service  action` 
> irrelevant 
> to which init-system is currently in use. Will it be systemd, or (whatever 
> there is alternative there). `service` wrapper will detect it anyway and will 
> do the proper things (forward it to either systemd or another service 
> manager).
> 
> I'd like to suggest to remove `service` widget from openrc and make it the 
> part of (which package? baselayout?)? Here is a pseudocode of how I see it:
> 
> ```
> servicename=${1}
> action=${2}
> 
> if in_systemd; then
>   systemctl "${action}" "${servicename}"
> else
>   rc-service "${servicename}" "${action}"
> fi
> ```
> 
> Well, actually, there may be some more logic (for example, instance units 
> (`unit@instance` in `systemd` vs `unit.instance` in openrc), "enable" action 
> (forward it to `rc-update add` for `openrc`, probably) and maybe some more.
> But anyway, the conception is something like that.
> 
> 
> What do you think about that?

https://xkcd.com/927/

We will create even more confusion for Gentoo users with one more
tool to do the same stuff.

Of course you are free to implement some separate wrapper package,
but it must be completely optional, since some users will have no
use for it including myself.

Really, unifying distributions is futile. We will have either the
same and only distribution (to rule them all) or an attempt will
fail. The same way you can try to unify emerge and apt tools via
some wrapper manager.

If one uses different distros, one needs to learn to switch between
them.

Best regards,
Andrew Savchenko


pgpiGustDpyxC.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

2017-09-07 Thread Andrew Savchenko
On Thu, 7 Sep 2017 15:04:34 +0200 Ulrich Mueller wrote:
> >>>>> On Thu, 7 Sep 2017, Rich Freeman wrote:
> 
> >>> Do we routinely confirm that any site we list in SRC_URI has
> >>> permission to redistribute files? That seems like a slippery
> >>> slope.
> >> 
> >> We don't, and for a package that comes with a license (as the vast
> >> majority of packages does) it normally isn't necessary.
> 
> > Why isn't this necessary?  How do you know the person issuing the
> > license actually has the right to issue it?
> 
> Don't you think there is a difference between downloading a package
> that has a known upstream and that is also carried by other distros,
> and downloading a license-less package from a random location on the
> internet?

If downloaded files are the same (e.g. sha512 hash matches), what's
the difference?

Best regards,
Andrew Savchenko


pgp10n1q4cpHA.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] git-r3.eclass: Explicitly warn about unsecure protocols

2017-09-03 Thread Andrew Savchenko
On Fri, 25 Aug 2017 17:46:01 +0200 Hanno Böck wrote:
> On Wed, 23 Aug 2017 11:46:02 +0300
> Andrew Savchenko <birc...@gentoo.org> wrote:
> 
> > Sigh... https also makes MITM attacks possible, especially if SSL
> > or TLS < 1.2 is used or are allowed and protocol version downgrade
> > attack may be performed.
> 
> None of that is true.
> 
> You're probably referring to attacks that were specific to certain
> browser weaknesses, but they're irrelevant for this use case.
 
Some attack are indeed implementation specific, but there are
several which are design flaws, e.g.:

1) BEAST attack[1]: TLS 1.0 is vulnerable regrardless of
implementation (and all SSL versions).

2) BREACH attack[2]: basically this is a side-channel attack for
compressed traffic. All TLS versions are still vulnerable, the only
practical mitigation is to disable compression. It can be argued if
this is a vulnerability in TLS or TLS protocol has nothing to do
with side channels, but if a protocol is vulnerable to a
side-channel implementation-agnostic attack, it is considered by
many as a protocol misdesign.

Really SSL/TLS are very good examples of how crypto solutions should
not be designed and implemented.

[1] https://www.gracefulsecurity.com/what-is-beast/
[2] http://breachattack.com/

Best regards,
Andrew Savchenko


pgpHlWZBJH1hu.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] git-r3.eclass: Explicitly warn about unsecure protocols

2017-09-03 Thread Andrew Savchenko
On Fri, 25 Aug 2017 15:51:25 +0200 Michał Górny wrote:
> W dniu śro, 23.08.2017 o godzinie 11∶46 +0300, użytkownik Andrew
> Savchenko napisał:
> > On Sat, 19 Aug 2017 10:25:02 +0200 Michał Górny wrote:
> > > Explicitly warn about any URI that uses an unsecure protocol (git, http)
> > > even if it's a fallback URI. This is necessary because an attacker may
> > > block HTTPS connections, effectively forcing the fallback to
> > > the unsecure protocol.
> > 
> > [...]
> > > + local r
> > > + for r in "${repos[@]}"; do
> > > + if [[ ${r} == git:* || ${r} == http:* ]]; then
> > > + ewarn "git-r3: ${r%%:*} protocol in unsafe and may be 
> > > subject to MITM attacks"
> > > + ewarn "(even if used only as fallback). Please use 
> > > https instead."
> > > + ewarn "[URI: ${r}]"
> > > + fi
> > > + done
> > > +
> > 
> > Sigh... https also makes MITM attacks possible, especially if SSL
> > or TLS < 1.2 is used or are allowed and protocol version downgrade
> > attack may be performed.
> > 
> > Such messages create a false impression of a safety of https.
> > Safety more or less can be gained by verifying GPG signatures and
> > fingerprints of the upstream commits, if upstream supports this. Of
> > course using https is better than using http or git, but better
> > only by a bit.
> > 
> 
> Yes, we can do a whole long debate about problems with HTTPS. Yes, we
> can do an even longer debate about all those fancy solutions that solve
> all the problems in the world, except they're completely not applicable
> in practice. People will become a lot wiser and/or depressed.
> 
> However, I'd rather do what I can practically do to make a real
> difference. And I believe that making things a little safer is better
> than claiming that nothing is safe, so let's just abandon all hope
> and continue using completely unsecured protocols.

I agree that better to have some improvement rather than nothing.

> Nevertheless, I've changed the wording a bit to avoid giving this 'false
> impression' that https is entirely secure.

Thanks, that was my main intent: to have correct docs.


Best regards,
Andrew Savchenko


pgp40FV5ZOm5W.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] git-r3.eclass: Explicitly warn about unsecure protocols

2017-08-23 Thread Andrew Savchenko
On Sat, 19 Aug 2017 10:25:02 +0200 Michał Górny wrote:
> Explicitly warn about any URI that uses an unsecure protocol (git, http)
> even if it's a fallback URI. This is necessary because an attacker may
> block HTTPS connections, effectively forcing the fallback to
> the unsecure protocol.
[...]
> + local r
> + for r in "${repos[@]}"; do
> + if [[ ${r} == git:* || ${r} == http:* ]]; then
> + ewarn "git-r3: ${r%%:*} protocol in unsafe and may be 
> subject to MITM attacks"
> + ewarn "(even if used only as fallback). Please use 
> https instead."
> + ewarn "[URI: ${r}]"
> + fi
> + done
> +

Sigh... https also makes MITM attacks possible, especially if SSL
or TLS < 1.2 is used or are allowed and protocol version downgrade
attack may be performed.

Such messages create a false impression of a safety of https.
Safety more or less can be gained by verifying GPG signatures and
fingerprints of the upstream commits, if upstream supports this. Of
course using https is better than using http or git, but better
only by a bit.

Best regards,
Andrew Savchenko


pgpHi59FnxDxv.pgp
Description: PGP signature


Re: [gentoo-dev] default entries for ALSA_CARDS, INPUT_DEVICES and VIDEO_CARDS

2017-08-18 Thread Andrew Savchenko
On Sun, 13 Aug 2017 22:56:30 +0200 Toralf Förster wrote:
> I do currently hard coded this for make.conf for every chroot imageat
> the tinderbox [1]:
> 
> 
> ALSA_CARDS="hda-intel"
> INPUT_DEVICES="evdev libinput"
> VIDEO_CARDS="intel"
> 
> 
> I think it is time to enhance that entries to vary it a little bit more
> and/or to leave it blank.Any suggestions ?

Do you have actual physical cards at your tinderbox? At least
VIDEO_CARDS may require this, e.g. with VIDEO_CARDS="nvidia"
ebuilds and tests may expect appropriate working kernel devices
(/dev/nvidiactl, /dev/nvidia0 and so on); test may actually use
OpenGL/OpenCL/CUDA and so on.

If yes, such testing will be quite useful, if no, it will give
false failures.

Best regards,
Andrew Savchenko


pgp8rgiwiaoKZ.pgp
Description: PGP signature


Re: [gentoo-dev] Perl 5.26 Unmasking Warning [affects all users]

2017-08-08 Thread Andrew Savchenko
On Wed, 9 Aug 2017 04:20:18 +1200 Kent Fredric wrote:
> We're finally at a point where we're nearing the unmasking[1] of Perl
> 5.26 and making it visible to ~arch users, and a "news item" on this
> matter will appear shortly.
> 
> Due to a collection of various problems faced in this version,
> extensive amounts of work has been needed to simply deliver an ~arch
> release that isn't incredibly visibly broken [1][2].

[1] indicates there are unfixed problems with core system packages:
gcc (620164) and autoconf (625576). Having them broken even in
~arch is no fun. Are you going to fix these issues before perl-5.26
will be unmasked?

[1] https://bugs.gentoo.org/show_bug.cgi?id=perl-5.26-unmask


Best regards,
Andrew Savchenko


pgpR_Hf6cX9QF.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] java-pkg-opt-2.eclass: fix java-pkg-opt-2_src_prepare to always call eapply_user for EAPI-6+

2017-08-07 Thread Andrew Savchenko
On Sun, 30 Jul 2017 22:08:18 +0100 James Le Cuirot wrote:
> On Sun, 30 Jul 2017 14:32:53 +0300
> Andrew Savchenko <birc...@gentoo.org> wrote:
> 
> > For EAPI 6+ java-pkg-opt-2_src_prepare() has eapply_user call via
> > java-utils-2_src_prepare() from java-utils-2.eclass. But
> > java-utils-2_src_prepare() call is conditional and in case when
> > package is build with USE=-java java-utils-2_src_prepare() is not
> > called, hence eapply_user is not called in src_prepare phase and
> > ebuild fails.
> > 
> > The following patch fixes this by calling eapply_user if java USE
> > is disabled _and_ EAPI is 6+.
> 
> This makes sense so no problem here.
> 
> > [pedantic mode on]
> > Strictly speaking when EAPI is other than [0-5]. The way java-*
> > eclasses are now, they assume ![0-5] == 6+. It may be speculated
> > that this is not entirely correct and many other eclasses
> > explicitly deny all unknown EAPIs. If someone is interesting in
> > fixing this issue, please handle it with the java team and do not
> > mix it into the problem described at the beginning. My goal now is
> > to fix eapply_user issue which cases trouble for any EAPI 6
> > packages with optional java support and default src_prepare() at
> > the ebuild scope.
> > [pedantic mode off]
> 
> Agreed. I don't think java-utils-2_src_prepare() should be changed in
> this regard as the behaviour may continue to be correct but the eclass
> should have a global EAPI check that forbids anything beyond 6 like
> other eclasses do.

Applied in the tree. The whitespace change from the original patch
is removed.

Best regards,
Andrew Savchenko


pgp3wWgzigZOK.pgp
Description: PGP signature


[gentoo-dev] [PATCH] java-pkg-opt-2.eclass: fix java-pkg-opt-2_src_prepare to always call eapply_user for EAPI-6+

2017-07-30 Thread Andrew Savchenko
Hi all,

For EAPI 6+ java-pkg-opt-2_src_prepare() has eapply_user call via
java-utils-2_src_prepare() from java-utils-2.eclass. But
java-utils-2_src_prepare() call is conditional and in case when
package is build with USE=-java java-utils-2_src_prepare() is not
called, hence eapply_user is not called in src_prepare phase and
ebuild fails.

The following patch fixes this by calling eapply_user if java USE
is disabled _and_ EAPI is 6+.

[pedantic mode on]
Strictly speaking when EAPI is other than [0-5]. The way java-*
eclasses are now, they assume ![0-5] == 6+. It may be speculated
that this is not entirely correct and many other eclasses
explicitly deny all unknown EAPIs. If someone is interesting in
fixing this issue, please handle it with the java team and do not
mix it into the problem described at the beginning. My goal now is
to fix eapply_user issue which cases trouble for any EAPI 6
packages with optional java support and default src_prepare() at
the ebuild scope.
[pedantic mode off]

Best regards,
Andrew Savchenko
diff --git a/eclass/java-pkg-opt-2.eclass b/eclass/java-pkg-opt-2.eclass
index 16c9f8f..c0b05f9 100644
--- a/eclass/java-pkg-opt-2.eclass
+++ b/eclass/java-pkg-opt-2.eclass
@@ -43,7 +43,11 @@ java-pkg-opt-2_pkg_setup() {
 # default src_prepare, wrapper for java-utils-2_src_prepare
 
 java-pkg-opt-2_src_prepare() {
-	use ${JAVA_PKG_OPT_USE} && java-utils-2_src_prepare
+	use ${JAVA_PKG_OPT_USE} && java-utils-2_src_prepare 
+	case "${EAPI:-0}" in
+		[0-5]) ;;
+		*) use ${JAVA_PKG_OPT_USE} || eapply_user ;;
+	esac
 }
 
 


pgpBNKAGqg2e6.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-29 Thread Andrew Savchenko
On Fri, 28 Jul 2017 12:44:20 +0200 Andreas K. Huettel wrote:
> Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
> > 
> > I hold a perhaps radical view: I would like to simply remove stable.
> > 
> > I continue to feel that maintaining two worlds (stable+unstable)
> > carries with it an unneccessary cost.
> > 
> 
> That's not feasible. It would kill off any semi-professional or professional 
> Gentoo use, where a minimum of stability is required. 
> 
> (Try keeping ~10 machines on stable running without automation. That's 
> already 
> quite some work. Now try the same with ~arch. Now imagine you're talking 
> about 
> 100 or 1000 machines.)
 
~50 hosts here on ~arch. Stable vs unstable is not an issue for
production. The main problem (at least in my case) is upgrade path,
especially with hosts not that often updated.

Upgrade of Gentoo-based production hosts takes considerable time,
not just due to compilation time and issues, but due to the need to
update dozens (sometimes hundreds) of config files properly and
this process can't be fully automated.

Another problem is short support time: only update path for systems
up to one year old is supported more or less. IRL even half year
old system may be PITA for a full update. To make it worse there
are cases when people deliberately make such updates harder: some
developers are refusing to set minimal version requirements for
dependencies if dependency versions below minimal were below latest
stable 1 year age. While such behaviour is within established
policies I frankly do not understand such devs: having
>=cat/foo-1.2.3 instead of cat/foo doesn't hurt, but makes life of
fellow users much easier.

Best regards,
Andrew Savchenko


pgplBwoP5YPz9.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-29 Thread Andrew Savchenko
On Thu, 27 Jul 2017 18:12:52 -0500 Denis Dupeyron wrote:
> On Mon, Jul 24, 2017 at 4:22 PM, Sergei Trofimovich <sly...@gentoo.org>
> wrote:
> 
> > TL;DR;TL;DR:
> >
> [...]
> 
> Here's a data point you may, or may not, find relevant. in 16 years of
> using Gentoo exclusively, the only one time I used stable on one machine
> for about 2 years it ended up being much more of a pain than unstable.
> Actually, I can't say I have anything to complain about unstable. On my
> critical machines I snapshot the system subvolume before I update. I can't
> remember the last time I had to roll back.

+1
I do not use stable, even in production. Too few packages, too old
versions, too long time to stabilize newer versions. I'm just OK
with ~arch.

> I'm sure most will disagree with me but since you're indirectly asking for
> my opinion here it is: I think people working on stable are wasting their
> time. But who am I to stop them...

I support stable in my packages, but mostly because I have to. One
of the real benefits from the stable for me is stabilization
process which sometimes uncovers otherwise undetected problems.

Of course there are people who use stable, I respect their opinion;
they have different use cases, practices, experience. So I'm not
asking to abandon stable, just explaining that for me and my cases
it is mostly useless.

Best regards,
Andrew Savchenko


pgprrqrPZspmA.pgp
Description: PGP signature


Re: [gentoo-dev] vim-syntax USE flag

2017-07-23 Thread Andrew Savchenko
On Sat, 22 Jul 2017 22:00:16 +0100 Sergei Trofimovich wrote:
> On Sat, 22 Jul 2017 16:27:39 -0400
> Mike Gilbert <flop...@gentoo.org> wrote:
> 
> > Packages currently handle installation of vim syntax support files
> > inconsistently. Some builds install the files if the "vim-syntax" USE
> > flag is enabled, while others install them unconditionally.
> > 
> > Do these files fall into the "small text files" category for
> > unconditional installation? If so, we should probably phase out the
> > vim-syntax USE flag.
> 
> I'd say use flag is not needed as long as it does not slow vim startup
> down by much and does not change editor behaviour for every single
> edited file type.

The problem here is more complicated. What about 100 plugins from
different packages which of them is fast enough, but together they
are slowing vim down to unacceptable level? Such case is
especially sensitive on slow hardware.

That's why fine control over vim files is mandatory. Yes, it
requires to rebuild packages, but with ccache/distcc available this
is not a huge issue. And if someone really want to avoid such
rebuilds, vim files can always be put to a separated package;
though I see no real reason to do this.

Using INSTALL_MASK here is not an option, because toggling of
individual vim files using it will be a nightmare.

Best regards,
Andrew Savchenko


pgpxlz5MXRPku.pgp
Description: PGP signature


Re: [gentoo-dev] can't gpg sign with repoman, but can with git

2017-07-19 Thread Andrew Savchenko
On Thu, 20 Jul 2017 00:44:12 +0300 Mart Raudsepp wrote:
> Ühel kenal päeval, K, 19.07.2017 kell 15:57, kirjutas Joshua Kinard:
> > On 07/19/2017 15:43, Andrew Savchenko wrote:
> > > On Wed, 19 Jul 2017 21:24:49 +0200 Paweł Hajdan, Jr. wrote:
> > > > Hey folks,
> > > > 
> > > > This is mysterious, and likely some issue with my setup, although
> > > > it
> > > > used to work.
> > > > 
> > > > Trying tocommit with repoman commit (app-portage/repoman version
> > > > 2.3.1)
> > > > results in the following:
> > > > 
> > > > * 4 files being committed...
> > > > error: gpg failed to sign the data
> > > > fatal: failed to write commit object
> > > > !!! Exiting on git (shell) error code: 128
> > > > 
> > 
> > [snip]
> > > 
> > 
> > [snip]
> > 
> > > Make sure that GPG_TTY is set in your shell.
> > 
> > ^^^--- This is likely the issue.
> > 
> > Add:
> > export GPG_TTY=`tty`
> > 
> > To your ~/.bash_profile (or wherever you put your PORTAGE_GPG_KEY
> > value), and
> > that should solve the issue.  I got bit by this once, and spent a
> > while
> > convincing Google that I'm not a robot to get that answer.
> 
> Sounds like a workaround, and yes, I know it's been suggested before,
> including to me.
> Some pinentry issues imho if GPG_TTY makes it work, at least it was
> when I hit that half a year ago with this suggested as a solution. It's
> not a solution, it's a workaround, as users need to do something.
> 
> FWIW, I don't have GPG_TTY set at all and things work fine, but I'm on
> pinentry-gnome3
> I think pinentry-curses and pinentry-tty might have had such trouble
> that need GPG_TTY stuff.

man gpg-agent says:

You should always add the following lines to your .bashrc or
whatever initialization file is used for all shell invocations:

 GPG_TTY=$(tty)
 export GPG_TTY

Thus there is no need to speculate if this is a workaround or if
one needs to convince Google they is not a robot. Just read the
official manual :)

Best regards,
Andrew Savchenko


pgp4XOI2PklUx.pgp
Description: PGP signature


Re: [gentoo-dev] can't gpg sign with repoman, but can with git

2017-07-19 Thread Andrew Savchenko
On Wed, 19 Jul 2017 21:24:49 +0200 Paweł Hajdan, Jr. wrote:
> Hey folks,
> 
> This is mysterious, and likely some issue with my setup, although it
> used to work.
> 
> Trying tocommit with repoman commit (app-portage/repoman version 2.3.1)
> results in the following:
> 
> * 4 files being committed...
> error: gpg failed to sign the data
> fatal: failed to write commit object
> !!! Exiting on git (shell) error code: 128
> 
> However, committing directly with git commit works (and asks for gpg
> passphrase).
> 
> In .git/config I have the following:
> 
> [user]
>   signingkey = 0x4F1A2555EA71991D
> [commit]
>   gpgsign = 1
> [push]
>   gpgsign = 1
> 
> In /etc/make.conf I have:
> 
> PORTAGE_GPG_KEY="0x4F1A2555EA71991D"
> 
> In ~/.gnupg/gpg-agent.conf I have the following:
> 
> pinentry-program /usr/bin/pinentry
> 
> eselect pinentry show prints pinentry-gnome3
> 
> I'm using app-crypt/gnupg-2.1.20-r1, last updated May 24.
> 
> Interestingly, I recently (July 17) re-emerged
> app-crypt/pinentry-0.9.7-r1, probably changing some USE flags. It may
> have been broken before that anyway, I don't remember now.
> 
> Most of all, I'm interested how to get more debug info from repoman than
> it currently shows me.
> 
> Any other insights would be welcome. Please let me know if you need any
> other info.

Try to see with strace what is going on. When some weird stuff
happens this is what I usually do.

Also try to switch pinentry to other implementations (ncurses, qt).
Make sure that GPG_TTY is set in your shell.

Best regards,
Andrew Savchenko


pgpPbBjgKVJD1.pgp
Description: PGP signature


Re: [gentoo-dev] Lastrites: app-mobilephone/esms, sci-chemistry/icm, dev-python/south...

2017-07-15 Thread Andrew Savchenko
On Fri, 14 Jul 2017 12:52:49 +0200 Pacho Ramos wrote:
> # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
> # games-engines/renpy cannot be used with its only reverse dep in the tree
> # as-is, it needs a major version bump and build fixing too, bug #587872.
> # Removal in a month.
> games-engines/renpy

I'll take it and its dev (dev-python/pygame_sdl2).

The funniest stuff about RenPy that native build allows to run
almost any RenPy games, even if they don't have Linux version built.

Best regards,
Andrew Savchenko


pgpS5aGCJ8WcV.pgp
Description: PGP signature


Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

2017-07-13 Thread Andrew Savchenko
On Thu, 13 Jul 2017 17:58:29 +0300 Andrew Savchenko wrote:
> On Thu, 13 Jul 2017 10:29:06 -0400 Mike Gilbert wrote:
> > On Thu, Jul 13, 2017 at 7:35 AM, M. J. Everitt <m.j.ever...@iee.org> wrote:
> > > On 13/07/17 12:09, Rich Freeman wrote:
> > >> Presumably you'd only want to remount it if it was mounted ro to
> > >> start, since it sounds like openrc will be diverging from systemd
> > >> behavior here.
> > >>
> > >> While it seems like a good idea I'm not sure how big an improvement it
> > >> is in the larger scheme.  We're worried about root accidentially
> > >> modifying efivars, but we have no safeguards against root writing to
> > >> /dev/sda, and the latter seems much more likely to cause harm, and is
> > >> harder to fix.
> > >>
> > > In case you weren't aware, Rich, rewriting the efivars actually writes
> > > to the system BIOS, which renders the computer completely unbootable ..
> > > not quite the same as erasing the boot sector of your hard disk, where
> > > you simply plug in another device, and Off you go ...
> > >
> > 
> > We are actually talking about protecting people who run something like
> > rm -rf /sys/firmware/efi/efivars/ as root.
> >
> > If you are dumb enough to do something like that, you almost deserve
> > to spend a couple hundred on a new motherboard.
>  
> Or just rm -rf /
> [pedantic]
> of course with newer rm versions one needs to run:
> rm -rf --no-preserve-root /
> or
> rm -rf /* /.*
> [/pedantic]
> 
> But in some scenarios this command is normal. E.g. user installs
> Gentoo from some live dvd/flash, makes some mistakes, understands
> that system is broken beyond repair and decides to start over again.
> If there is no need to recreate filesystem itself or partition
> layout, running rm -rf / as above is quite reasonable.
> 
> When running this command user expects to kill the data, but not
> the hardware. That is my point. I can't call such action dumb.

One more example: remember the bumblebee install script bug[1]: due
to a typo the whole /usr was removed, the same may happen with /sys
one day.

If simple file removal results in dead hardware this is no go.

[1]
https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123

Best regards,
Andrew Savchenko


pgpwMLacdGc2x.pgp
Description: PGP signature


Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

2017-07-13 Thread Andrew Savchenko
On Thu, 13 Jul 2017 10:29:06 -0400 Mike Gilbert wrote:
> On Thu, Jul 13, 2017 at 7:35 AM, M. J. Everitt <m.j.ever...@iee.org> wrote:
> > On 13/07/17 12:09, Rich Freeman wrote:
> >> Presumably you'd only want to remount it if it was mounted ro to
> >> start, since it sounds like openrc will be diverging from systemd
> >> behavior here.
> >>
> >> While it seems like a good idea I'm not sure how big an improvement it
> >> is in the larger scheme.  We're worried about root accidentially
> >> modifying efivars, but we have no safeguards against root writing to
> >> /dev/sda, and the latter seems much more likely to cause harm, and is
> >> harder to fix.
> >>
> > In case you weren't aware, Rich, rewriting the efivars actually writes
> > to the system BIOS, which renders the computer completely unbootable ..
> > not quite the same as erasing the boot sector of your hard disk, where
> > you simply plug in another device, and Off you go ...
> >
> 
> We are actually talking about protecting people who run something like
> rm -rf /sys/firmware/efi/efivars/ as root.
>
> If you are dumb enough to do something like that, you almost deserve
> to spend a couple hundred on a new motherboard.
 
Or just rm -rf /
[pedantic]
of course with newer rm versions one needs to run:
rm -rf --no-preserve-root /
or
rm -rf /* /.*
[/pedantic]

But in some scenarios this command is normal. E.g. user installs
Gentoo from some live dvd/flash, makes some mistakes, understands
that system is broken beyond repair and decides to start over again.
If there is no need to recreate filesystem itself or partition
layout, running rm -rf / as above is quite reasonable.

When running this command user expects to kill the data, but not
the hardware. That is my point. I can't call such action dumb.

Best regards,
Andrew Savchenko


pgpglDBADe5p7.pgp
Description: PGP signature


Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

2017-07-13 Thread Andrew Savchenko
On Thu, 13 Jul 2017 12:35:50 +0100 M. J. Everitt wrote:
> On 13/07/17 12:09, Rich Freeman wrote:
> > Presumably you'd only want to remount it if it was mounted ro to
> > start, since it sounds like openrc will be diverging from systemd
> > behavior here.
> >
> > While it seems like a good idea I'm not sure how big an improvement it
> > is in the larger scheme.  We're worried about root accidentially
> > modifying efivars, but we have no safeguards against root writing to
> > /dev/sda, and the latter seems much more likely to cause harm, and is
> > harder to fix.
> >
> In case you weren't aware, Rich, rewriting the efivars actually writes
> to the system BIOS, which renders the computer completely unbootable ..
> not quite the same as erasing the boot sector of your hard disk, where
> you simply plug in another device, and Off you go ...
 
It may be even worse. Some parts of efivars may be stored not in the
BIOS chip, but on other chips like AC control or IME. So simple
BIOS reflashing (e.g. from backup BIOS available on many boards)
will not help.

Best regards,
Andrew Savchenko


pgpEd02MrkduP.pgp
Description: PGP signature


Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

2017-07-13 Thread Andrew Savchenko
On Thu, 13 Jul 2017 07:54:44 -0400 Rich Freeman wrote:
[...]
> >> Presumably you'd only want to remount it if it was mounted ro to
> >> start, since it sounds like openrc will be diverging from systemd
> >> behavior here.
> >>
> >> While it seems like a good idea I'm not sure how big an improvement it
> >> is in the larger scheme.  We're worried about root accidentially
> >> modifying efivars, but we have no safeguards against root writing to
> >> /dev/sda, and the latter seems much more likely to cause harm, and is
> >> harder to fix.
> >
> > Writing to /dev/sda may kill data stored there, but hardware itself
> > will survive. Writing to efivars kills hardware and this is the
> > motivation for this change. See [1] and [2] for details. Poettering
> > says this is OK to hard brick device, well fine, this is systemd
> > way. OpenRC is smarter here and protects users from unintended
> > disaster.
> 
> Reading through those apparently bricking is considered to be a
> hardware bug.  Granted, it is still desirable to avoid.

Yes, it can be considered as a hardware bug, as well as thousands
of other issues, look at how many quirks are inside the kernel.
This is how it works: software works around hardware bugs, because
software is so much easier to update than hardware.

> In any case, tools would still need to be compatible with both
> approaches.  Apparently there are commands like systemctl reboot
> --firmware-setup that expect this to be writable.  If we aren't going
> to make the default ro under systemd then tools will need to handle
> both cases.  If we decide to change the default for systemd (or put a
> line in the default fstab) then this issue would go away.

I see no problems with compatibility. In case of software needs to
write to efivars (bootloader installation, etc) algo is simple:

flag = false;
if (mounted(efivars) == RO) { remount(efivars, RW); flag = true; }
do_usual_stuff();
if (flag) remount(efivars, RO);

Best regards,
Andrew Savchenko


pgpABpM2nsz3F.pgp
Description: PGP signature


Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

2017-07-13 Thread Andrew Savchenko
On Thu, 13 Jul 2017 07:09:45 -0400 Rich Freeman wrote:
> On Thu, Jul 13, 2017 at 2:30 AM, Andrew Savchenko <birc...@gentoo.org> wrote:
> > On Wed, 12 Jul 2017 17:42:50 -0700 Matt Turner wrote:
> >> On Wed, Jul 12, 2017 at 5:29 PM, Lucas Ramage <ramage.luca...@gmail.com> 
> >> wrote:
> >> > What needs to be changed for the bootloaders? I may be able to assist.
> >>
> >> The documentation should be updated to say that with OpenRC 0.28 that
> >> you'll have to remount efivars as RW before you can install the
> >> bootloader (e.g., grub-install)
> >>
> >> The command I use locally to remount rw (since I have configured
> >> efivars to be mounted read-only in fstab) is
> >>
> >> mount -o remount,rw /sys/firmware/efi/efivars
> >
> > We don't have that much efi bootloaders. Maybe it will be better
> > to update their scripting to remount efivars rw and back ro when
> > needed? The same way we have non-efi bootloaders to mount /boot
> > partition when needed.
> >
> 
> Presumably you'd only want to remount it if it was mounted ro to
> start, since it sounds like openrc will be diverging from systemd
> behavior here.
> 
> While it seems like a good idea I'm not sure how big an improvement it
> is in the larger scheme.  We're worried about root accidentially
> modifying efivars, but we have no safeguards against root writing to
> /dev/sda, and the latter seems much more likely to cause harm, and is
> harder to fix.

Writing to /dev/sda may kill data stored there, but hardware itself
will survive. Writing to efivars kills hardware and this is the
motivation for this change. See [1] and [2] for details. Poettering
says this is OK to hard brick device, well fine, this is systemd
way. OpenRC is smarter here and protects users from unintended
disaster.

Data can be restored from backup, but hard bricked hardware may
become completely dead beyond repair or require a very complicated
soldering. So I see this issue much more serious than writing
to /dev/sda.

[1] https://github.com/openrc/openrc/issues/134
[2] https://github.com/systemd/systemd/issues/2402

Best regards,
Andrew Savchenko


pgpTuFWVf3Gda.pgp
Description: PGP signature


Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

2017-07-13 Thread Andrew Savchenko
On Wed, 12 Jul 2017 17:42:50 -0700 Matt Turner wrote:
> On Wed, Jul 12, 2017 at 5:29 PM, Lucas Ramage <ramage.luca...@gmail.com> 
> wrote:
> > What needs to be changed for the bootloaders? I may be able to assist.
> 
> The documentation should be updated to say that with OpenRC 0.28 that
> you'll have to remount efivars as RW before you can install the
> bootloader (e.g., grub-install)
> 
> The command I use locally to remount rw (since I have configured
> efivars to be mounted read-only in fstab) is
> 
> mount -o remount,rw /sys/firmware/efi/efivars

We don't have that much efi bootloaders. Maybe it will be better
to update their scripting to remount efivars rw and back ro when
needed? The same way we have non-efi bootloaders to mount /boot
partition when needed.


Best regards,
Andrew Savchenko


pgpzrhuYWcaEJ.pgp
Description: PGP signature


Re: [gentoo-dev] taking a break from arches stabilization

2017-07-10 Thread Andrew Savchenko
On Mon, 10 Jul 2017 16:27:54 -0400 Rich Freeman wrote:
> On Mon, Jul 10, 2017 at 4:05 PM, M. J. Everitt <m.j.ever...@iee.org> wrote:
> > This is why stabilisation, if not for individual package maintainers on
> > amd64, has become a joke, save for Ago's efforts, and recent efforts by
> > kensington to streamline the effort for the likes of ago with his bot,
> > and one or two other arch stabilisers (who I know exist, but not by name
> > or nick).
> 
> Sure.  If nobody is maintaining stable keywords on an arch, then there
> shouldn't be stable keywords on that arch, unless the stable keywords
> are used for a different purpose and maintainers are free to downgrade
> them at any time.

I'm confused, again. I can't find any official policy regarding
dekeywording packages from stable to testing.

Can developers remove packages from stable on whim or only on
certain conditions? Under what conditions exactly? Should arch
teams be notified on such actions? Or even requested permissions
from?

IMO a valid reason to remove from stable is arch team failure to
stabilize this package for a long time. But how long? Month, two,
half a year?

What to do with reverse dependencies? Should they be dropped to
~arch altogether with the package in question? Or should their
maintainers be given a warning before? How long to wait after?
One more month or two, another half a year?

Maybe I should move this discussion to the wg_stable ML, but
there are few people there and gentoo-dev has much wider coverage.

A well established arch -> ~arch policy should help to keep number
of stable packages sane and manageable for arch teams. A well
established policy of doing ~arch -> arch by devs themselves will
help to lower load on arch teams as well. So for everyone be happy
(arch teams by keeping them stable and manageable, devs by solving
stabilization requests in a sane time) we need good policies!

Best regards,
Andrew Savchenko


pgpGBPh8B9Gld.pgp
Description: PGP signature


Re: [gentoo-dev] taking a break from arches stabilization

2017-07-10 Thread Andrew Savchenko
On Mon, 10 Jul 2017 22:17:34 +0200 Kristian Fiskerstrand wrote:
> On 07/10/2017 10:02 PM, Rich Freeman wrote:
> > On Mon, Jul 10, 2017 at 3:57 PM, Andrew Savchenko <birc...@gentoo.org> 
> > wrote:
> >>
> >> On Mon, 10 Jul 2017 13:49:40 -0400 Rich Freeman wrote:
> >>
> >>> In the case of amd64 we already
> >>> encourage individual package maintainers to stabilize their own
> >>> packages
> >>
> >> Huh? Have our rules changed? As per devmanual[1] and GLEP 40[2]
> >> stabilization must be carried out by arch teams, unless a special
> >> arrangement is done between a developer and a team.
> >>
> > 
> > The docs are probably out of date - I'm not sure if the policy is
> > documented anywhere.  However it has been a fairly longstanding policy
> > at this point that amd64 allows individual maintainers to stabilize
> > their own packages.
> > 
> 
> We looked after it for wg-stable (which died out as a result of rather
> low participation, maybe it should be rebooted if people feel like
> discussing this again), there isn't any authoritative policy allowing
> it, GLEP:40 explicitly removes the possibility to do it for x86. That
> said, for a number of packages maintainer stabilization can likely make
> sense, the opposite view is four-eyes principle, it is always good to
> have someone else build-test etc, but this is greatly helped by
> tinderboxing efforts (thanks toralf) etc. So one likely output if
> wg-stable is to come up with something would be a replacement GLEP for
> 40 that matches the current state, and also kernel auto-stabiliation (as
> discussed in [section 3.2 (Kernel)]

So, am I understanding this correctly that right now a package
stabilization by maintainer without explicit permit from an arch
team will be the violation of active and approved policies?

Despite the maintainer-driven stabilization seems to be "a fairly
longstanding policy" I'm reluctant to do such stabilization myself,
because anyone may point out later that such action is a violation
of the written policies and I will have nothing to defend me.

Even if such stabilization is allowed, there are unanswered
questions here:
- is following seciton 4.1 from wg recommendations is sufficient?
- should developer test each stabilization candidate on an
up-to-date stable setup?

Best regards,
Andrew Savchenko


pgpYEUqvw0qvV.pgp
Description: PGP signature


Re: [gentoo-dev] taking a break from arches stabilization

2017-07-10 Thread Andrew Savchenko
Hi,

On Mon, 10 Jul 2017 13:49:40 -0400 Rich Freeman wrote:
> On Mon, Jul 10, 2017 at 1:22 PM, Agostino Sarubbo <a...@gentoo.org> wrote:
> >
> > Now, since I work on these arches just to help, i.e. I don't have any 
> > business
> > and I do non have any installation of those arches and the work I'm doing is
> > not appreciated at all I decided to stop for now.
> 
> I wouldn't say that your work is unappreciated.  However, when those
> are called "unmaintained" arches it reflects the fact that very few
> are contributing to them.  The nature of a linux distro is that one
> person could be working 24x7 with bleeding fingers and it would be
> like sticking a finger in a dike.  It takes more than one contributor
> (even a serious one) to make something like this viable.
> 
> > I will take a break also from amd64 and x86...let's see how things will
> > change.
> 
> I'm not sure I really see the connection but you're of course welcome
> to work on whatever you want to.  In the case of amd64 we already
> encourage individual package maintainers to stabilize their own
> packages, and I think this is much more sustainable than having an
> arch team do it.

Huh? Have our rules changed? As per devmanual[1] and GLEP 40[2]
stabilization must be carried out by arch teams, unless a special
arrangement is done between a developer and a team.

[1] https://devmanual.gentoo.org/keywording/index.html
[2] https://wiki.gentoo.org/wiki/GLEP:40

Best regards,
Andrew Savchenko


pgpZLjzLZyEkc.pgp
Description: PGP signature


Re: [gentoo-dev] Re: lua upgrade plan

2017-07-02 Thread Andrew Savchenko
Hi,

On Sun, 2 Jul 2017 10:30:12 -0500 William Hubbs wrote:
> > All that said, in FLOSS, he who volunteers, makes the rules, and 
> > particularly given the upstream opposition meaning more gentoo-level work 
> > required, if there's nobody willing to support lua in gentoo with dynamic 
> > linking...
>  
> You are correct. Basically we have to write our own build system and
> keep it up to date for every version of lua in order to support this. 

Why should we? We can borrow from other distributions like Debian
or Fedora. Of course some Gentoo-specific tuning may be required,
but it will be not writing from scratch.

> If someone can convince upstream to support it, this would be far better for
> everyone.

In the ideal world, yes, I agree with this. But we are in real
world with real lua developers unwilling to cooperate from what I
see.

Best regards,
Andrew Savchenko


pgpfTv0Yi8lEB.pgp
Description: PGP signature


Re: [gentoo-dev] Hardening a default profile

2017-06-17 Thread Andrew Savchenko
On Thu, 15 Jun 2017 19:52:07 -0500 Matthias Maier wrote:
> > there should be a way of turning these off systematically.  the
> > advantage of the current hardened gcc specs is that one can switch
> > between them using gcc-config.  if these are forced on for the default
> > profile then there will be no easy way to systematically turn them off.
> 
> No - there won't be an easy way for systematically turning off
> SSP and PIE in 17.0 profiles [1,2].
> 
> The hardened toolchain with its different gcc profiles came from a time
> where SSP and PIE were relatively new security features and a certain
> amount of fine-grained control was needed. Further, at that time we were
> talking about external patches against gcc. Nowadays everything is
> upstreamed and (almost) no patches to gcc for hardened profiles are
> applied any more.
> 
> Given the fact that all major linux distributions are following the path
> of improved default hardening features (see for example [1]) and that we
> have been using ssp/pie in hardened profiles for years now the purpose
> of fine-grained control over ssp/pie is also highly questionable.
> 
> The consensus at the moment is that PIE and SSP (as well as stricter
> linker flags) will soon be standard (or, actually *are* already
> standard) compilation options. A per-package override (if absoluetely
> needed) is fine - and, in fact, already in place everywhere where
> needed.

Gentoo is all about choice, remember? :)

It is really good to have them by default, it is bad to force them
on everyone. Security is not always of paramount importance
comparing to other factors, sometimes performance matters more,
e.g. in isolated and restricted non-public HPC environment.

PIE, SSP may lead up to 8% of performance loss[1]. The
stack-protector (especially stack-protector-all or -strong) may
cause even more damage. For compute nodes this may be equivalent to
millions USD loss (depends on the system scale of course).

[1] https://bugs.archlinux.org/task/18864

Best regards,
Andrew Savchenko


pgpmrLyPiaNJH.pgp
Description: PGP signature


  1   2   3   4   >