Re: [gentoo-dev] Packages up for grabs: x11-misc/xscreensaver

[Andrey Utkin]

On Thu, Mar 11, 2021 at 11:30:44PM +0100, Jonas Stein wrote:
> the following packages are up for grabs after dropping
> desktop-misc:
> 
> x11-misc/xscreensaver
> https://packages.gentoo.org/packages/x11-misc/xscreensaver
> 
> It has 3 open tickets.

Hi,

Strongly considering picking it up.
Please don't remove in the meanwhile.


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Andrey Utkin]

I agree with the proposal to sunset LibreSSL.
Supporting it benefits very few users due to how non-universal the support of
this option is. I see it as entirely sensible choice on apps' upstreams part to
not collaborate on libressl support, motivation being focusing on more typical
user setups.

But I have one loosely related question. About USE=bindist of openssl & openssh.

My impression is that when you spin up a new Gentoo setup from stage3, very
early on you are typically forced by situations to switch off USE=bindist for
openssl and openssh. I conclude that one can't redistribute more elaborate
system images and binpkgs because of this.

However there's no `bindist` flag and therefore no such situation with libressl
package. I never did good research of why this is so, so I am still wondering:
what does that mean in practice?

Does this mean libressl has some advantage for binary redistributability of
elaborate system images and binary packages?


signature.asc
Description: PGP signature

[gentoo-dev] Up for grabs: dev-util/tup, ...

[Andrey Utkin]

Hi fellows,

The following packages are up for grabs:

* dev-util/tup

  Two outstanding issues:
  https://bugs.gentoo.org/show_bug.cgi?id=711856
  https://bugs.gentoo.org/show_bug.cgi?id=704990

* media-gfx/propaganda

  A collection of graphics.
  No open bugs. No other package depends on it.

* dev-python/guzzle_sphinx_theme

  No open bugs.
  A dependency of dev-python/botocore.
  Maintainers of botocore have been notified directly.


signature.asc
Description: PGP signature

[gentoo-dev] Packages up for grabs

[Andrey Utkin]

I have transitioned to "away" state as I have to reclaim my time for other
uses. Here I am trying to reduce the scope of my Gentoo responsibilities to
make potential return to activity less dreadful and overwhelming.

Call for successors
===

The following are the packages I do not currently use myself so have the least
motivation about. Dropping me from maintainers list is encouraged.

WIFI access point service:

* net-wireless/hostapd
(Co-maintained by zerochaos, still additional attention is encouraged.)

Python API for AWS:

* dev-python/s3transfer
* dev-python/boto3
* dev-python/botocore
* dev-python/guzzle_sphinx_theme

TUI XMPP clients:

* net-im/mcabber
* net-im/poezio
* net-im/profanity
* net-libs/loudmouth
* dev-libs/libstrophe
* dev-python/slixmpp


Somewhat obscure build system:

* dev-util/tup

V4L:

* media-libs/libv4l
* media-tv/v4l-utils


Call for co-maintainers or successors
=

For these I have some minor use. You can expect me to have some interest 
revived.
Still, taking responsibility for them in my absence is highly appreciated.

GUI XMPP client:

* net-im/dino
* net-libs/libsignal-protocol-c

XMPP server software:

* net-im/spectrum2
* net-im/swift

Raspberry Pi packages:

* media-libs/raspberrypi-userland-bin
* sys-boot/raspberrypi-firmware
* sys-kernel/raspberrypi-image
* sys-kernel/raspberrypi-sources

CardDAV CLI tool:

* app-misc/khard
* dev-python/ruamel-std-pathlib
* dev-python/ruamel-yaml-clib
* dev-python/ruamel-yaml


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

[Andrey Utkin]

Since it is going to be opt-in and optional anyway, we seem to be fine with
having just partial data.

I assume we have logs of distfiles downloads from Gentoo infrastructure, and
can negotiate access to relevant logs of our mirrors. That constitutes partial
data correlated with users' installation activity, as good as it gets.

If we do have some such data, are we using it in any way for the discussed
purposes?

If we don't, but could get it, would we be able to use that data for these
purposes? If no, why?

If we can't get the data, why?


As an aside, I think the best known way to ensure the availability of important
things, from user perspective, is to pay for these important things. Of course
I see how this won't fit culturally very well here and that we're not going to
switch to commercial model just for this reason.


signature.asc
Description: Digital signature

[gentoo-dev] [RFC] News Item: sys-boot/raspberrypi-firmware will not install device tree files

[Andrey Utkin]

Title: sys-boot/raspberrypi-firmware will not install device tree files
Author: Andrey Utkin 
Content-Type: text/plain
Posted: 2019-11-25
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-boot/raspberrypi-firmware

sys-boot/raspberrypi-firmware up to and including version 1.20190709
installed files /boot/*.dtb and /boot/overlays/*. Newer versions will no
longer install these files.

These files will be installed by sys-kernel/raspberrypi-image package.

If you do not use sys-kernel/raspberrypi-image, you need to install
these files according to the method you use to install the kernel. For
installation from source, this can be done with such a command:

make dtbs_install

This change is being made to enable arm64 users and custom kernels users
to use sys-boot/raspberrypi-firmware package.
See https://bugs.gentoo.org/685412


signature.asc
Description: Digital signature

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

[Andrey Utkin]

I am also against the part of the proposal about maintainer being
responsible to prebuild the docs.

I'd also like to note that Gentoo users are empowered to locally bump
ebuild versions in this insanely easy way, it almost always works, and
it is really useful at times.

With this policy, this instanely easy way will work with lower
probability, because one would need to work around the missing docs
package for the new version.

Also, I don't see how this would work for proxy-maintained packages and
just with external contributions.

Proxies team members have to trust the docs prebuilt by non-devs?
Or they have to build the docs themselves as part of procedure of
acceptance of external contribution?

Perhaps what they can do to stay safe is to sidestep external
contributions which touch such packages.


P.S.

Not a great argument, but I just want to say this: source-based
nature of Gentoo has ingrained the feeling in me that not only
everything is open for studying, but also that, most of time, the result
of package installation on user's machine is "sterile", not tainted by
any interference from middlemen.

I think the currently discussed issue is not critical. Feels odd to
reduce the source-based nature because of that.


signature.asc
Description: Digital signature

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

[Andrey Utkin]

On Thu, Jun 20, 2019 at 09:53:46AM -0400, Brian Evans wrote:
> What significance will such numbers have when a daemon uses a new
> UID/GID and really doesn't care what it is?  Why do we have to go
> through the effort of assigning fixed IDs at random?

One reason not mentioned by mjo: this paves the way to resolution of
very old frustrating problem with user/group creation when
cross-compiling entire system from scratch.

See https://bugs.gentoo.org/541406


signature.asc
Description: Digital signature

Re: [gentoo-dev] Introducing global USE=gui flag

[Andrey Utkin]

On Sun, Apr 21, 2019 at 07:09:12PM +0200, David Seifert wrote:
> Dear fellow developers,
> as part of our effort in making Gentoo more pleasant to use, I am
> suggesting to add the global USE=gui flag.

The idea seems sensible to me.
What should be the next step?
An experimental patchset handling some tricky packages in the proposed
way?


signature.asc
Description: Digital signature

Re: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware

[Andrey Utkin]

On Fri, Mar 15, 2019 at 03:03:58PM +0100, Conrad Kostecki wrote:
> Could we keep this package? I can take it, and make a proper release, if that 
> would be enough to keep this package? I am using this on my gentoo with my 
> Rpi3.

Hi Conrad,

Thank you for being this active!

I am also interested in using this and keeping it in Gentoo, so let's
team up!


signature.asc
Description: Digital signature

Re: [gentoo-dev] Packages up for grabs due to tetromino's retirement

[Andrey Utkin]

On Sun, Mar 10, 2019 at 10:52:24AM +0100, Michał Górny wrote:
> media-libs/libv4l
> media-tv/v4l-utils

I have some familiarity with these, I'll take them.
(Everybody is welcome to co-maintain if they wish so.)


signature.asc
Description: Digital signature

Re: [gentoo-dev] AUTHORS file for portage repository

[Andrey Utkin]

On Tue, Nov 27, 2018 at 01:50:31PM -0800, Matt Turner wrote:
> So let's satisfy everyone and be done with it: Let's put AUTHORS in
> Git with a section header that states that these Copyright holders are
> not obvious from the git history. This is where Sony would go.

We can make it obvious from the git history, can't we?

commit 
Author: Dev on Payroll 
AuthorDate: 
Commit: Dev on Payroll 
CommitDate: 

commit title

commit description

Signed-off-by: Dev on Payroll 
Signed-off-by: Dev on Payroll 


signature.asc
Description: Digital signature

Re: [gentoo-dev] AUTHORS file for portage repository

[Andrey Utkin]

On Tue, Nov 27, 2018 at 09:12:26AM -0600, William Hubbs wrote:
> All,
> 
> based on the previous thread about copyright attribution clarifications,
> I want to add the following AUTHORS file to the top level of the portage
> repository if no one objects.
> 
> This is based on the description of the AUTHORS file at Google [1].
> 
> Everyone is not required to be listed, but  there is no reason you can't
> add yourself if you have contributed to the tree and want to be listed.
> 
> I hope this will satisfy everyone involved in the discussion.
> 
> Thoughts?

It seems to me this will grow huge, and be the source of annoyance for
users.

There's a plausible opinion that today's Unixes will stay around
forever:
https://utcc.utoronto.ca/~cks/space/blog/unix/DurableCurrentUnixes

And obviously Gentoo is the best flavour of them, so...

Are there any long-lived community FOSS projects maintaining such file?
FFmpeg had such one (CREDITS file), but eschewed it in 2013 for a short
notice "check git log".


signature.asc
Description: Digital signature

Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format

[Andrey Utkin]

On Wed, Nov 21, 2018 at 11:45:54AM +0100, Fabian Groffen wrote:
> We agree it is hackish, and we agree we can do without.  You simply
> exaggerate the problem, IMO, which mostly isn't there, because it works
> fine today.  It can also be solved today using shell tools.

I am sad that you don't see it as a productivity impediment that the
user is required to know the custom tooling to do even such a trivial
non-standard action as manual extraction.

Maybe I will make myself look bad by admitting this, but I'm not meeting
your expectations. I use Gentoo for ~11 years, and for about one year I
am using my private binpkgs distributed to all my machines (i.e. I have
read binary package guide fair number of times, but I stopped rereading
it when I satisfied my needs). When in need, I still reached to trusty
tar, and I did not even know what are the names of special tools (a
toolchain?) qtbz2 and qxpak.

Just few days ago I messed with binpkgs for investigation purpose. I
just wanted to extract few to somewhere (definitely not into system
root), and read a core dump with GDB asking it to use those extracted
files for debug symbols.

Of course I used `tar xaf`, because what I know is that it's honest tbz2
just with metadata appended.

 # tar xaf boost-1.65.0.tbz2

bzip2: (stdin): trailing garbage after EOF ignored

Exit code is 0.
But the notice is annoying (on subconscious level), because Silence Is
Golden - "when a program has nothing interesting or surprising to say,
it should shut up".

> % head -c `grep -abo 'XPAKPACK' 
> $EPREFIX/usr/portage/packages/sys-apps/sed-4.5.tbz2 | sed 's/:.*$//'` 
> $EPREFIX/usr/portage/packages/sys-apps/sed-4.5.tbz2 | tar -jxf -
> 
> results in no warnings/errors from bzip about trailing garbage, possible
> thanks to the spec being smart enough about this.

Thanks, this is a very concise **custom tool** to handle current binpkg
format.

> Not having to do this, when under stress and pressure to restore a
> system to get it back into production, is a plus.  Though, in that
> scenario the trailing garbage warning wouldn't have been that bad
> either.

When understress and pressure, the irrelevant warning is not bad?
I am sure it is really bad for operator's attention.


signature.asc
Description: Digital signature

Re: [gentoo-dev] Packages up for grabs

[Andrey Utkin]

On Sun, Jul 01, 2018 at 10:57:40AM +0200, Pacho Ramos wrote:
> net-im/mcabber
> net-libs/loudmouth

Taking these.


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] Personall Gentoo Installer project pre-beta release

[Andrey Utkin]

Hi,

First, my appreciation for your work!

I am not going to check it out myself, but I'd enjoy watching a
screencast, or at last a series of screenshots, of how it looks and
works.


signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: empty directories in ${D}

[Andrey Utkin]

On Thu, Mar 29, 2018 at 11:57:06AM -0400, Alec Warner wrote:
> On Thu, Mar 29, 2018 at 11:47 AM, Michael Orlitzky  wrote:
> 
> > On 03/29/2018 11:28 AM, Alec Warner wrote:
> > >
> > > Is there any particular reason we need to remove them?
> > >
> >
> > The PMS says that empty directories are undefined, so the portage
> > behavior of installing them and leaving them alone leads to
> > incompatibilities. Ebuilds rely on the portage behavior, and if another
> > PM (within its rights) deletes them, then the package breaks with the
> > non-portage PM.
> >
> >
> So we could simply change the PMS to keep the empty directories?
> 
> Why is removing them *better* is my question.

Right, I am not aware why PMS has left this explicitly undefined. Have
read through https://bugs.gentoo.org/644366 but there's no hint on why,
too. I appreciate mjo's proposal. I think it would be good for ebuild
maintainer to have a switch "empty dirs are ok by default". The
disagreement seems to be based on a prejudice and distrust towards
upstreams' build systems.


signature.asc
Description: Digital signature

Re: [gentoo-dev] Packages up for grabs

[Andrey Utkin]

On Tue, Mar 13, 2018 at 03:11:45PM +0100, Lars Wendler wrote:
> On Tue, 13 Mar 2018 12:58:10 +0100 Pacho Ramos wrote:
> 
> >net-wireless/hostapd
> 
> In case nobody else wants to take it I can do. But I'm a mere user of
> the package and don't know anything about its internals. So it would be
> very basic/low maintenance from me.

I can't let this get dropped from the tree :)
I'm mere user, too, let's comaintain. Please put us both to
metadata.xml (in whichever order you prefer).


signature.asc
Description: Digital signature

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

[Andrey Utkin]

On Thu, Mar 08, 2018 at 05:57:35PM +0100, Jeroen Roovers wrote:
> On Thu, 08 Mar 2018 16:40:44 +0100
> Michał Górny  wrote:
> 
> > As part of that we also shouldn't deliver static libraries
> 
> OK, so you want to absolutely kill dead the only current sane way for
> developers who use Gentoo to ship static binaries to their users'
> target systems? Drive them away to another Linux distro that does
> support being the build platform that they need? Or force everyone to
> use EXTRA_ECONF"--enable-static" and hope for them that it works for
> all packages? All just because static linking *between* ebuilds is bad?

This is close to my current case. Trying (in my own time) to build a
(hopefully elegant) demo setup of Gentoo & crossdev with static libs
enabled, to present as an alternative to CentOS which is currently the
build env at my job (and static linkage is the way the product is built
now). I run into cross-compilation problems when I enable
USE=static-libs to any extent, despite the comment in Gentoo's fake
/usr/lib64/*.so files saying "And yes, this works in the cross-
compiling scenario as the sysroot-ed linker will prepend the real path".
But it's what I'd rather have resolved than have no USE=static-libs at
all.


signature.asc
Description: Digital signature

Re: [gentoo-dev] Packages up for grabs

[Andrey Utkin]

> sys-power/acpid

Taking this one.


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml

[Andrey Utkin]

On Sat, Jun 03, 2017 at 08:19:32PM +1200, Kent Fredric wrote:
> On Sat, 03 Jun 2017 09:58:28 +0200
> Michał Górny  wrote:
> 
> > and that's a small one. I guess we could avoid this if you restricted
> > those remotes to the source package used to build them all.
> 
> I think in the event they're a form of conventional 
> 
>   foo
>   foo-dev
>   foo-dbg
> 
> etc, under the knowledge that those things can't possibly map to other
> gentoo packages, we should codify only the first of those, and then have
> it placed on the iteroperating code to make logical inferences from
> that.
> 
> "foo-dev" in a search query would map to "foo" if no "foo-dev" existed.
> 
> But yeah, lots of complexity there.
> 
> That's why I'd just say those facets shouldn't really be mapped
> explicitly.
> 
> The general pattern being:
> 
>  "If a debian id can be conjugated from another debian id by guessing
> with a generic algorithm, only index the former"

It is common for debian package names contain version numbers, besides
other ugliness:

https://packages.debian.org/search?keywords=libavcodec=names=stable=all

You have searched for packages that names contain libavcodec in suite(s)
stable, all sections, and all architectures. Found 4 matching packages.
Package libavcodec-dev
Package libavcodec-extra
Package libavcodec-extra-56
Package libavcodec56

Obviously numbered package name libavcodec56 can be an attribute of
exact ebuild, but not of a Gentoo package.

With this ugliness of Debian packages naming, I'm afraid the proposed
change won't take off.

Re: [gentoo-dev] News item for uclibc-ng

[Andrey Utkin]

On Wed, Feb 08, 2017 at 02:37:52PM -0500, Anthony G. Basile wrote:
> Hi everyone,
> 
> Attached you'll find a news item for uclibc-ng.  I'd like to push it out
> in a few days.
> 

> This will make sure all executables link directly against libc.so.0 (as
> reported by `readelf -d`) rather than via sym links like libdl.so.0 ->
> libc.so.0.  Then upgrade from 1.0.19 to 1.0.20 without symlink-combat:
> 
> USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20

First quote sign is non-ascii so command doesn't work when copy-pasted
to terminal.

Re: [gentoo-dev] Help wanted with www-client/chromium

[Andrey Utkin]

On Tue, Dec 13, 2016 at 06:00:25PM -0500, Mike Gilbert wrote:
> Keeping up with the frequent Chromium releases is quite a chore.
> Recently, phajdan.jr has been slacking on the masked dev channel
> updates due a hardware problem, so I have been spending additional
> time on them.
> 
> If there are any developers with relatively fast hardware that could
> take on the stable and/or beta channel updates, that would be most
> appreciated. This is also something that could be done by a trusted
> user.
> 
> Help with the masked dev channel is also welcome -- especially testing
> the various USE flags and unbundling libraries.

Have reasonably powerful amd64 hardware, can try nightly runs.

Not an affiliated gentoo developer.

I guess it would be best to make up collectively a tiny git repo with
scripts which do exactly what is needed?

First of all it could be a set of chromium builds with different use
flags (a set of such configurations needs to be defined), saved as
binary packages, so that all the builds could be tested at once by
unpacking every build, in turn. All build logs must be saved for review,
and failures should be reported. Makes sense? Ideas? Comments?

Re: [gentoo-dev] Please retain authorship of contributed patches

[Andrey Utkin]

On Thu, Dec 01, 2016 at 12:50:42PM -0800, Daniel Campbell wrote:
> I completely agree that we should credit (and thank) contributors. I'm
> not sure if I'm doing things correctly, but when I'm dealing with a bug
> and users contribute patches or edits to ebuilds, I try to credit them
> in my commit message, often asking them which nickname they'd prefer so
> I can give credit to the "right" name. Is this a practice you find adequate?

As turned out, the problem was lack of communication rather than
misprocessing of original contribution.

In Git, t's harder to erase the original authorship than to retain it,
so I don't see the need to discuss subtleties here. Common practice I
see in such projects as FFmpeg and Kernel is to pick the original patch
if possible, or, if credit must be given just for mere concept, the
contributor is mentioned in "Suggested-by:" line or just informally.

> Thanks for bringing this to attention. It's somewhat related to another
> discussion we've been having about copyright, and it may be worth
> considering protocol for situations like the one you've outlined.

Could you  please give a link to archives of that discussion?

Re: [gentoo-dev] Please retain authorship of contributed patches

[Andrey Utkin]

Hi Matthew,

Please take my deepest excuses for unjustly blaming you, now I see that
my perception was plain wrong in being so blindly emotional.

On Wed, Nov 30, 2016 at 05:43:36PM -0600, Matthew Thode wrote:
> While I did see your PR and bug if I remember correctly I didn't
> actually use your commit or your ebuild to source it.  I added it based
> on the bug iirc (which is still waiting on the link it seems).

Indeed, the link to PR was never added to bugzilla ticket, which is odd
on my side. I guess I could have connectivity issues back then.

> I should
> have mentioned that bug at the very least though and/or worked with you
> on the ebuild.

> Again, sorry about not updating the bug or waiting to work with you on
> the PR.  If there's something else I can do for this let me know.

Again sorry for false accusation and not getting in touch with you
before starting public discussion.

Re: [gentoo-dev] Please retain authorship of contributed patches

[Andrey Utkin]

On Thu, Dec 01, 2016 at 02:27:17AM +0300, Andrew Savchenko wrote:
> One more reason to use merge commits for pull requests: original
> author commits with proper authorship will be retained.
> 
> Yes, I know that some people are unhappy with non-linear history,
> but this is how git works, so there is nothing wrong with merge
> commits for user-contributed changes.

Hi Andrew,

I don't see this subject as valid reason to prefer merge commits over
rebases. Personally I prefer linear history and rebases.

I had a commercial project in my practice which was based on Github, and
other developers submitted pull requests. My workflow was to rebase the
proposed changes onto mainline branch (which of course preserves
authorship data), push the updated mainline branch to central repo, and
close the PR manually. Not much of work, linear history, git metadata
preserved.

[gentoo-dev] Please retain authorship of contributed patches

[Andrey Utkin]

I'm quite sure this angry rant won't be pleasant to read for anybody,
but still I believe this post serves the good of Gentoo and this issue
is technical enough to be discussed on gentoo-dev. Also gentoo-pr list
seems retired anyway.

This is a second time I've got into a situation when a new ebuild
submitted by me gets to mainline with minimal changes but not retaining
my authorship at all.

First time it was here: https://github.com/gentoo/gentoo/pull/361 and my
rant was endorsed by monsieurp and the committer made excuses.

This time the discussion between me and the committer has never
happened.

My PR: https://github.com/gentoo/gentoo/pull/2765

My bugzilla ticket linked to it:
https://bugs.gentoo.org/show_bug.cgi?id=599088

After my pull request from Nov 6, the following commit gets into mainline:

commit e19f46dfca967f4195eedf3f37a7882fbb37b796
Author: Matthew Thode 
Date:   Tue Nov 15 13:55:17 2016 -0600

dev-python/secretstorage: adding for keyring

Package-Manager: portage-2.3.0


The difference between my submission and final variant by Matthew is big
in number of lines, but is trivial in content as you can see below, so I
don't believe that Matthew has written his variant from scratch on his
own (he hasn't given any note on tickets on bugs.g.o or github), it
seems more like intentional swapping and amending original lines
retaining identical outcome.

Not that authorship of one or two commits is so crucial for me, or that
I'm the most ambitious wannabe-contributor. Hell, there's not much of
code at all in the ebuild - it's trivial; but also not much is needed
here to give credit. I have contributed to quite some FOSS projects, and
have run into theft of my patches a couple of times, and it never was by
pure accident.

I beg affiliated Gentoo developers to stay sane and be thinking not just
about numbers of your commits, but also about community spirit and
relationships. Of course inexperienced contributor gets things not right
first. In such cases, great maintainers fix that and retain original
authorship; good maintainers request for changes and resubmission.

In no way I'm going to drift away from Gentoo because of this issue, no
alternatives around. (I even have a gradually maturing idea to become
Gentoo contributor on regular basis.)

Just for record, a list of projects I've contributed to: FFmpeg, Linux
kernel, VLC, GStreamer, Kamailio, Mcabber, Gajim, v4l-utils.


diff --git a/336a45f661 b/98c5361d66
index 336a45f661..98c5361d66 100644
--- a/336a45f661
+++ b/98c5361d66
@@ -1,19 +1,27 @@
-# Copyright 2016 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Id$
 
-EAPI="6"
-PYTHON_COMPAT=( python2_7 python3_{3,4,5} )
+EAPI=6
+PYTHON_COMPAT=( python{2_7,3_4,3_5} )
 
 inherit distutils-r1
 
-DESCRIPTION="Python bindings to FreeDesktop.org Secret Service API"
-HOMEPAGE="http://pypi.python.org/pypi/SecretStorage;
-SRC_URI="mirror://pypi/${PN:0:1}/${PN}/${P}.tar.gz"
+MY_PN="SecretStorage"
+
+DESCRIPTION="Python bindings to FreeDesktop.org Secret Service API."
+HOMEPAGE="https://github.com/mitya57/secretstorage 
https://pypi.python.org/pypi/SecretStorage;
+SRC_URI="mirror://pypi/S/${MY_PN}/${MY_PN}-${PV}.tar.gz"
 
 LICENSE="BSD"
 SLOT="0"
-KEYWORDS="~amd64 ~x86"
+KEYWORDS="amd64 ~arm64 x86 ~amd64-linux ~x86-linux"
+IUSE=""
+
+DEPEND="dev-python/setuptools[${PYTHON_USEDEP}]"
+
+RDEPEND="
+   dev-python/cryptography[${PYTHON_USEDEP}]
+   dev-python/dbus-python[${PYTHON_USEDEP}]"
 
-RDEPEND="dev-python/dbus-python[${PYTHON_USEDEP}]
-   dev-python/cryptography[${PYTHON_USEDEP}]"
+S="${WORKDIR}/${MY_PN}-${PV}"