Re: [gentoo-dev] Last rites: next Python 2 batch

2020-09-09 Thread Azamat Hackimov
Hello.

> games-rpg/adonthell
> games-rpg/wastesedge

Created PR https://github.com/gentoo/gentoo/pull/17483 for these packages.

-- 
>From Siberia with Love!



Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation

2020-09-08 Thread Azamat Hackimov
Marek,

Is there any plans how to begin migrating lua packages to new eclass?
As I can see, the current stable dev-lang/lua:0 package is not suited
for it, while other slotted packages have major flaws about *.pc
handling.

вт, 8 сент. 2020 г. в 17:32, Marek Szuba :
>
> Merged, thank you everyone who has weighed in with their comments both
> on IRC and here.
>
> --
> MS
>


-- 
>From Siberia with Love!



Re: [gentoo-dev] [PATCH 1/2] eclass: Add first version of lua.eclass

2020-09-06 Thread Azamat Hackimov
Hello!

Some notes from me.

чт, 3 сент. 2020 г. в 16:37, Marek Szuba :

> +# @ECLASS-VARIABLE: LUA
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# The absolute path to the current Lua interpreter. This variable is set
> +# automatically in functions called by lua_foreach_impl().
> +#
> +# Example value:
> +# @CODE
> +# /usr/bin/lua5.1

I think there also needs a LUAC variable that points to the current
Lua compiler.

> +# @FUNCTION: lua_get_version
> +# @USAGE: []
> +# @DESCRIPTION:
> +# Obtain and print the full version number of the given Lua implementation.
> +# If no implementation is provided, ${ELUA} will be used.
> +#
> +# Please note that this function requires Lua and pkg-config installed,
> +# and therefore proper build-time dependencies need be added to the ebuild.
> +lua_get_version() {
> +   debug-print-function ${FUNCNAME} "${@}"
> +
> +   _lua_export "${@}" LUA_VERSION
> +   echo "${LUA_VERSION}"
> +}

There needs a LUA_MAJOR_VERSION (V variable in lua.pc, i.e. 5.1, 5.2,
5.3) instead of full version (R variable in lua.pc, i.e 5.1.5, 5.2.4).
Some obscure Lua packages are required to define V variable to work
properly.



[gentoo-dev] bitbucket.org mercurial repositories shutdown

2020-08-20 Thread Azamat Hackimov
Hello all.

BitBucket announced mercurial repositories shutdown in April 2020 [1]
with an effective date July 2020. Now all mercurial repositories
switched to offline with message "Repository unavailable - Bitbucket
no longer supports Mercurial repositories".
Today we have 63 packages with bitbucket.org in the SRC_URI and/or
HOMEPAGE variables in the tree. Here online list [2] and tracker bug
[3]. Please note, that BitBucket retired only mercurial repositories,
git repos are unaffected.

Please fix the ebuilds, in order to save them from getting on the
treeclean candidates list. Quick analysis says that most of the
projects have already moved their repositories to other sites (like
Github or Heptapod).

List of packages:

# name src_uri_fetch_error homepage_fetch_error
app-dicts/dikt True False
app-emulation/pcem False True
app-portage/pqlop True True
app-text/csvfix True True
app-vim/frawor True True
app-vim/gundo True False
app-vim/splice True False
dev-cpp/eigen True False
dev-db/sadisplay False True
dev-games/ogre True False
dev-haskell/equivalence False True
dev-haskell/fdo-notify False True
dev-haskell/setlocale False True
dev-haskell/stringsearch False True
dev-python/backports False True
dev-python/blockdiag False True
dev-python/chainmap False True
dev-python/cov-core False True
dev-python/cssutils False True
dev-python/django-auth-ldap False True
dev-python/et_xmlfile False True
dev-python/openpyxl True False
dev-python/polib False True
dev-python/pycountry False True
dev-python/pypeg2 False True
dev-python/pypy True False
dev-python/pypy3 True False
dev-python/pypy3-exe True False
dev-python/pypy-exe True False
dev-python/pytest-cache False True
dev-python/reportlab False True
dev-python/ruamel-std-pathlib True True
dev-python/sphinxcontrib-doxylink False True
dev-python/sphinxcontrib-newsfeed False True
dev-python/suds False True
dev-python/tempita True False
dev-python/whoosh False True
dev-ruby/pg False True
dev-vcs/tortoisehg True False
games-action/lugaru False True
games-arcade/opentyrian False True
mail-filter/courier-pythonfilter False True
media-gfx/qiv True True
media-libs/coin True True
media-libs/SoXt True False
media-libs/x265 True True
media-plugins/vdr-dvbhddevice True False
media-tv/v4l-dvb-saa716x True False
media-video/atomicparsley-wez True False
media-video/transcode False True
net-dns/mdns-repeater True True
net-misc/connect True True
net-misc/qtm True False
net-misc/sks True True
net-nds/shelldap True True
net-wireless/rfcat True True
sci-libs/ignition-math True False
sci-libs/tensorflow True False
sys-fs/fuse-zip True True
sys-power/ncpufreqd False True
x11-misc/openbox-menu True False
x11-plugins/purple-hangouts True True
x11-plugins/wmcpuwatch True True

[1] https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
[2] https://wiki.gentoo.org/wiki/Upstream_repository_shutdowns/bitbucket.org
[3] https://bugs.gentoo.org/737896

-- 
>From Siberia with Love!



Re: [gentoo-dev] Packages up for grabs due to jlec being MIA

2020-08-06 Thread Azamat Hackimov
Taking dev-lua/luaposix
https://github.com/gentoo/gentoo/pull/17032

ср, 5 авг. 2020 г. в 10:24, Michał Górny :
>
> Hello,
>
> The following packages are looking for a new maintainer:
>
> [vB] app-backup/cachedir
> [vB] app-benchmarks/bootchart2
> [ B] app-benchmarks/ramspeed
> [ B] app-office/scribus
> [vB] dev-lua/luaposix
> [ b] net-analyzer/zmap
> [  ] net-libs/czmq
> [  ] net-vpn/vpncwatch
> [vB] sys-block/blocks
> [  ] sys-boot/makebootfat
> [v ] sys-fs/aufs-headers
> [vB] sys-fs/aufs-util
> [vB] sys-fs/bcache-tools
> [v ] sys-kernel/aufs-sources
> [vB] sys-kernel/kergen
>
> Legend:
>
> v - needs version bump
> b - has trivial (QA) bug reported
> B - has non-trivial bug reported
>
> --
> Best regards,
> Michał Górny
>


-- 
>From Siberia with Love!



Re: [gentoo-dev] Last rites: */* More Py2 only items

2020-06-29 Thread Azamat Hackimov
> dev-python/misaka
I've created MR for it: https://github.com/gentoo/gentoo/pull/15984


-- 
>From Siberia with Love!



Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-20 Thread Azamat Hackimov
> games-emulation/openmsx

git version migrated to meson and python3



[gentoo-dev] State of Lua in Gentoo, Part Two

2020-05-28 Thread Azamat Hackimov
Hello.

There have been discussions about the status of the Lua in Gentoo
earlier[1][2][3], but they have not led to any progress: we are still
stuck on Lua 5.1, which is approaching to EOL. And there almost ready
lua 5.4 on the sight... I would like to return to the discussion of
the problems with the Lua, which over a period of more than 7 years
have accumulated quite a lot.

Firstly, an assembly system is needed that would allow adapt new
versions of lua without heavy patchwork. I suggest using one of the
options that other distributions already use - for example, RedHat use
autotools[4], we can adapt their works or write our own, for example,
on cmake or meson.

Secondly, we need to make the lua available in the system as a regular
dependency for other packages. Here I also suggest to use working of
RedHat and Debian, which offer a rather convenient mechanism through
the pkg-config, which we also have, but in a broken state.

It is also important to keep in mind that in a lua there are the
concepts of LMOD (pure lua modules that depend only on it, install
path is /usr/share/lua/5.{1,2,3}) and CMOD (modules that require
external dependencies and install shared libraries, install path is
/usr/lib/lua/5.{1,2,3}). This smoothly takes us to the third question
- slotting the package. The current implementation is broken by
design; it does not implement a coherent hierarchy, all dependent
packages will instantly broke. Also, it does not solve the problem of
smooth migration between major versions. We need a lua.eclass, like a
ruby or a python, which could fully manage slotted versions.

The final question is the migration of the current lua package
ecosystem. There are not many of them in the repository (I mean
directly the lua modules, there about 40 dev-lua/* packages in
desperate state), so we can relatively easily migrate them. There is
also a Luarocks[5] package manager in lua, which we could adapt to our
future ecosystem.


[1] 
https://archives.gentoo.org/gentoo-dev/message/49b75e2dfa21d1a72c9531a9054389dd
[2] 
https://archives.gentoo.org/gentoo-dev/message/c1dbc4a812dd41bfce9abd165ac9cf39
[3] 
https://archives.gentoo.org/gentoo-dev/message/489dd050913744a35aa1e8df5d43c85a
[4] https://git.centos.org/rpms/lua/blob/c8/f/SOURCES
[5] https://luarocks.org/

-- 
>From Siberia with Love!



Re: [gentoo-dev] RFC: Gentoo Identity Provider

2020-05-19 Thread Azamat Hackimov
вт, 19 мая 2020 г. в 09:47, Michał Górny :
>
> On Mon, 2020-05-18 at 18:42 -0700, Alec Warner wrote:
> > TL;DR: What if we launched id.gentoo.org, an identity provider that
> > provides authentication for Gentoo properties? Basically, 1 username /
> > password for wiki, bugs, email, forums, and any other http service[0][1].
> >
> > Today Gentoo has numerous systems that mostly work in a segmented way.
> >
> >  - To connect to hosts, we use ssh keys.
> >  - Git is authenticated via ssh keys.
> >  - Email uses LDAP passwords.
> >  - Bugzilla has its own identities, with their own passwords.
> >  - Wiki is separate, with its own passwords.
> >  - Forums are separate.
> >  - Infra has an additional 4 systems that use separate credentials.
> >
> > Some applications support 2FA (such as wiki.)
> > Some applications do not support 2FA.
> > Applications that require 2FA have a configuration for each app, so you
> > have N configurations.
> >
> > If we configured id.gentoo.org you would have 1 identity across all gentoo
> > properties.
> >
> > Is this a thing people are interested in?
> >
>
> What a coincidence I've just archived our old identity.gentoo.org [1]
> project.  And yes, we almost had this back in 2013 but Infra failed to
> deploy, and it was claimed obsolete by the time I joined Infra.
>
> Do you have any specific solution in mind?
>
> [1] https://gitweb.gentoo.org/archive/proj/identity.gentoo.org.git/
>
>
> --
> Best regards,
> Michał Górny
>

Hi there.

Maybe better to try something already stable, like KeyCloak [1]? Seem
all that you need (OpenID, LDAP, SAML2, external Identity Providers
via OpenID) is already implemented.

[1] https://www.keycloak.org/

-- 
>From Siberia with Love!



Re: [gentoo-dev] packages up for grabs

2020-01-10 Thread Azamat Hackimov
Hello.

I can take dev-lua/* packages.


чт, 9 янв. 2020 г., 22:08 Rafael Goncalves Martins :

> app-emulation/qemu-init-scripts
> app-text/txt2tags
> dev-lua/luadoc
> dev-lua/luaexpat
> dev-lua/luafilesystem
> dev-lua/luarocks
> dev-lua/luasec
> dev-lua/toluapp
> dev-vcs/mercurial-server
> www-apps/trac-accountmanager
> www-apps/trac-mercurial
> www-apps/trac-tags
>
> --
> Rafael 
>


Re: [gentoo-dev] uid/gid request for www-apps/redmine

2019-10-24 Thread Azamat Hackimov
OK, I will take 451 uid/gid for redmine.

чт, 24 окт. 2019 г. в 21:02, Michael Everitt :

> On 24/10/19 18:58, Azamat Hackimov wrote:
>
> Hello.
>
> As per https://github.com/gentoo/gentoo/pull/12807 I need UID/GID for
> web-application Redmine. Could I please get those for it? Any available
> number will OK.
>
> --
> From Siberia with Love!
>
> Check https://api.gentoo.org/uid-gid.txt .. give it a couple of weeks, if
> nobody objects, post a confirmation.. voila!
>


-- 
>From Siberia with Love!


[gentoo-dev] uid/gid request for www-apps/redmine

2019-10-24 Thread Azamat Hackimov
Hello.

As per https://github.com/gentoo/gentoo/pull/12807 I need UID/GID for
web-application Redmine. Could I please get those for it? Any available
number will OK.

-- 
>From Siberia with Love!


[gentoo-dev] UID/GID for www-applications

2019-08-29 Thread Azamat Hackimov
Hello.

I need UID/GID for www-apps/redmine. Originally package creates own user
and group named redmine, but I think it's better to create generic
user/group for all web-applications, like www-data in Debian/Ubuntu or http
in Arch.
Is there any suggestions about this proposal?

-- 
>From Siberia with Love!


Re: [gentoo-dev] git checkout in ebuild?

2017-10-16 Thread Azamat Hackimov
Github creates tarballs for tags automatically, for 1.3.0 tag it would be
https://github.com/intelsdi-x/snap/archive/1.3.0.tar.gz, so you don't need
to use git eclass.
SRC_URI would look like:

SRC_URI="https://github.com/intelsdi-x/snap/archive/${PV}.tar.gz ->
${P}.tar.gz"

2017-10-16 11:13 GMT+05:00 :

> October 16, 2017 5:30 AM, "Damo Brisbane"  wrote:
>
> Hello,
>
> I am wanting to make an ebuild for Intel's (Apache 2 licensed) snap
> monitoring framework
> (https://github.com/intelsdi-x/snap). It seems the current version
> (2.0.0) does not compile the
> golang binaries with some type of recent grpc API incompatibility. I can
> successfully compile by
> going:
>
> go get ...
>
> cd 
>
> git checkout 1.3.0
>
> make all
>
> This gets me the binaries (snaptel, snapteld); does anyone know if I can
> put this process (git
> checkout..) into an .ebuild file (or some other suggestion)?
>
> Cheers,
>
>
> Hi,
>
> You can use git-r3.eclass and use a specific tag or commit.
> See examples on the tree :
> https://github.com/gentoo/gentoo/search?utf8=%E2%9C%93;
> q=EGIT_COMMIT+git-r3=
>
> Best regards,
> --
> Corentin “Nado” Pazdera
>



-- 
>From Siberia with Love!


Re: [gentoo-dev] lua upgrade plan

2017-07-01 Thread Azamat Hackimov
2017-06-30 22:16 GMT+05:00 William Hubbs :

> All,
>
> Upstream does not support liblua as a shared library, and they do not
> support installing multiple versions of lua onto a system. After
> conferring with the other lua maintainer, the decision has been made to
> remove this custom support from our lua package as well. This has been
> talked about many times upstream.


Lua devs very "hostile" to Linux distributers. I don't see why we should do
as they want to do.
They not have open vcs to simply see what they changes in new release, they
don't accepts
patches for system integration. They didn't even elementary easy-to-use
build system. Just
look to another distributives, they all do versioned and shared libraries
of Lua 5.{1,2,3}. Fedora
devs did custom Autotools-based buildsystem, Debian - provided pkg-config
files. There also
exists excellent LuaDist framework - still outdated, yes, but we can take
from them CMake
buildsystem to provide better integration into Gentoo enviroment. You have
so many options
but you still want to follow unwelcome Lua rules.


> They do not want it, and using liblua as a shared library causes
> performance issues.
>

Why, we live in XXI century, where this argument came from? What about
security, did you
forgot about it? How do you planning to do backward compatibility with old
lua5.1 libraries
and projects? They definitely have breakage since lua 5.2 and 5.3 not
compatible with each
other. Why Lua can't have same eclass as multislotted Python or Ruby? Lua
ecosystem not
so big, about 500 packages so why there no even little efforts to make Lua
support in Gentoo
better?

-- 
>From Siberia with Love!


Re: [gentoo-dev] Last rites: ruby21-only packages

2017-06-24 Thread Azamat Hackimov
Hello.

I submitted proxy-maintainer request some time ago for redmine:
https://bugs.gentoo.org/show_bug.cgi?id=590646
And here PR for new 3.3.3: https://github.com/gentoo/gentoo/pull/4550


2017-06-24 14:23 GMT+05:00 M. J. Everitt :

> On 23/06/17 08:45, Hans de Graaff wrote:
> > # Hans de Graaff  (23 Jun 2017)
> > # Mask ruby21-only packages for removal in 30 days
> >
> > # ruby21-only, no maintainer
> > www-apps/redmine
> Really? I find it hard to believe that a common package like redmine is
> ruby-21 only?!
>
> http://www.redmine.org/projects/redmine/wiki/redmineinstall#Ruby-
> interpreter
> seems to agree.
>
> I could proxy this in the event no-one steps forward, as I quite like
> the front-end.
>
> Might need a bit of a hand on the R-on-R stuff if it was available
> somewhere ... !
>
> Best regards,
>
> Michael.
>
>


-- 
>From Siberia with Love!


[gentoo-dev] Status of Lua in Gentoo

2016-08-03 Thread Azamat Hackimov
Hello, everyone!

I noticed, that dev-lang/lua in have serious troubles in Gentoo. There no
Lua project, which would coordinate support. However, packages that depends
on lua-5.2, could not be builds successfully against installed lua:5.1 and
lua:5.2 [1][2]
Is there any roadmap for transition to slotted 5.1/5.2 packages and
unhardmasking? As I understand, we need to rewrite eselect-lua, or even to
create lua.eclass for that.
I can offer assistance in resolving these problems, as I need lua-5.2/5.3
for a number of packages.

[1] https://bugs.gentoo.org/show_bug.cgi?id=524460
[2] https://bugs.gentoo.org/show_bug.cgi?id=539828

-- 
>From Siberia with Love!