Re: [gentoo-dev] Packages up for grabs: sys-firmware/broadcom-bt-firmware

[Azamat Hackimov]

Hello.
I can take it since I'm the author of the broadcom-bt-firmware project.

чт, 23 мар. 2023 г. в 11:10, Florian Schmaus :
>
> I've dropped
>
>   sys-firmware/broadcom-bt-firmware
>
> to maintainer needed, as I do not longer have compatible hardware.
>
>  From a security perspective, the firmware in this package could be
> considered dubious. Personally, I would recommend users to by newer
> bluetooth hardware [1].
>
> The package has one open bug, requesting USE=savedconfig support:
> https://bugs.gentoo.org/buglist.cgi?quicksearch=broadcom-bt-firmware
>
> - Flow
>
> 1: I now have a TP-Link UB500, and I am quite happy with it.



-- 
>From Siberia with Love!

Re: [gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?

[Azamat Hackimov]

Also, according to commit history, dynamic exception usage was removed
in 
https://github.com/vlabella/GLE/commit/14753e9aba9eb6490358caaeb60f6e36ba314acc,
so you can try to apply this patch.

сб, 17 дек. 2022 г. в 16:05, Azamat Hackimov :
>
> Hello.
>
> You need to add
>
> set(CMAKE_CXX_STANDARD 14)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
>
> into CMakeLists.txt after project() declaration via patching. Since
> this is an upstream issue, you need to notify upstream about C++17
> incompatibility.
>
> сб, 17 дек. 2022 г. в 14:35, Andrey Grozin :
> >
> > Hello *,
> >
> > I'm trying to package a new version of sci-visualization/gle which now
> > uses cmake. After some patching CMakeLists.txt, it configures
> > successfully. But at build time it spits zillion errors
> >
> > error: ISO C++17 does not allow dynamic exception specifications
> >
> > The natural thing to try is to add -std=c++14 to CXXFLAGS. So I tried
> >
> > src_compile() {
> >  CXXFLAGS="${CXXFLAGS} -std=c++14" cmake_src_compile
> > }
> >
> > but this makes no difference, c++17 is still used. How to convince
> > cmake_src_compile to use -std=c++14?
> >
> > Thanks in advance,
> > Andrey
> >
>
>
> --
> From Siberia with Love!



-- 
>From Siberia with Love!

Re: [gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?

[Azamat Hackimov]

Hello.

You need to add

set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

into CMakeLists.txt after project() declaration via patching. Since
this is an upstream issue, you need to notify upstream about C++17
incompatibility.

сб, 17 дек. 2022 г. в 14:35, Andrey Grozin :
>
> Hello *,
>
> I'm trying to package a new version of sci-visualization/gle which now
> uses cmake. After some patching CMakeLists.txt, it configures
> successfully. But at build time it spits zillion errors
>
> error: ISO C++17 does not allow dynamic exception specifications
>
> The natural thing to try is to add -std=c++14 to CXXFLAGS. So I tried
>
> src_compile() {
>  CXXFLAGS="${CXXFLAGS} -std=c++14" cmake_src_compile
> }
>
> but this makes no difference, c++17 is still used. How to convince
> cmake_src_compile to use -std=c++14?
>
> Thanks in advance,
> Andrey
>


-- 
>From Siberia with Love!

Re: [gentoo-dev] Package up for grabs: app-arch/snappy

[Azamat Hackimov]

Well, with a little patch magic, I was able to make GTest suite as an
optional dependency.
Here PR: https://github.com/gentoo/gentoo/pull/20692

ср, 5 мая 2021 г. в 21:09, Michał Górny :

> On Wed, 2021-05-05 at 19:47 +0300, Azamat Hackimov wrote:
> > Strangely enough, upstream actually released new 1.1.9 a few hours ago. I
> > don't see any issues with git submodules (there only gtest and benchmark
> > libraries which can be disabled via cmake).
> > Anyway, I can take maintainership over it.
> >
>
> Disabling the tests is not a solution.
>
> --
> Best regards,
> Michał Górny
>
>
>
>

-- 
>From Siberia with Love!

Re: [gentoo-dev] Package up for grabs: app-arch/snappy

[Azamat Hackimov]

Strangely enough, upstream actually released new 1.1.9 a few hours ago. I
don't see any issues with git submodules (there only gtest and benchmark
libraries which can be disabled via cmake).
Anyway, I can take maintainership over it.

ср, 5 мая 2021 г. в 12:54, Michał Górny :

> Hi,
>
> The following package needs a new maintainer:
>
>   app-arch/snappy
>
> Technically, it's not a high traffic package.  It's pending version bump
> but upstream did not bother providing a working release archive,
> and GitHub archives do not work because they are missing git submodules.
>
> That said, it's a typical Google open source package -- bad quality,
> doesn't care the slightest bit about accepting patches or getting bug
> reports, or even making working releases.
>
> --
> Best regards,
> Michał Górny
>
>
>
>

-- 
>From Siberia with Love!

Re: [gentoo-dev] Last rites: sys-power/ncpufreqd, app-text/csvfix

[Azamat Hackimov]

чт, 28 янв. 2021 г. в 00:09, Robin H. Johnson :
>
> It's useful in data processing pipelines; I agree it has a few
> buggy/broken edges, but for the most part it just works on all of my
> data needs.

OK, let's give it second chance: https://github.com/gentoo/gentoo/pull/19243

-- 
>From Siberia with Love!

[gentoo-dev] Last rites: sys-power/ncpufreqd, app-text/csvfix

[Azamat Hackimov]

+# Azamat H. Hackimov  (2021-01-26)
+# Dead upstream (last release 2007), unmaintained, multiple issues,
+# no reverse dependencies.
+# Removal in 30 days. Bug #744019
+sys-power/ncpufreqd
+
+# Azamat H. Hackimov  (2021-01-26)
+# Dead upstream, no live HOMEPAGE and SRC_URI.
+# Removal in 30 days. Bug #744013
+app-text/csvfix

-- 
>From Siberia with Love!

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

[Azamat Hackimov]

Hi.
Also created https://github.com/gentoo/gentoo/pull/18411 for taking
maintainership.

чт, 26 нояб. 2020 г. в 12:01, Bernard Cafarelli :
>
> Le Thu, 26 Nov 2020 00:27:53 +0100
> Jonas Stein  a écrit:
>
> > Dear all
> >
> > the following packages are up for grabs while dissolving
> > the desktop-misc project:
> >
> > x11-misc/zim
> > https://packages.gentoo.org/packages/x11-misc/zim
> >
> > It is a very powerful deskop wiki which is written in python. It has
> > many users and it would be great if you would take care for it.
> >
> > It has one open bug with a fix in the comments.
> > https://bugs.gentoo.org/678436
>
> I will take care of it
>
> --
> Bernard Cafarelli (Voyageur)
> Gentoo developer
>


-- 
>From Siberia with Love!

Re: [gentoo-dev] Last rites: sys-apps/sydbox, sys-libs/pinktrace

[Azamat Hackimov]

Actually there PR for sydbox assigned to you:
https://github.com/gentoo/gentoo/pull/16117

вт, 17 нояб. 2020 г. в 12:34, Michał Górny :
>
> # Michał Górny  (2020-11-17)
> # Fail to build with gcc-10.  No recent activity upstream.  Seems that
> # Exherbo is dead and buried.
> # Removal in 30 days.  Bug #708528.
> sys-apps/sydbox
> sys-libs/pinktrace
>
> --
> Best regards,
> Michał Górny
>


-- 
>From Siberia with Love!

Re: [gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua

[Azamat Hackimov]

вт, 6 окт. 2020 г. в 15:54, Brian Evans :
>
> On 10/6/2020 8:45 AM, Azamat Hackimov wrote:
> > вт, 6 окт. 2020 г. в 15:04, Marek Szuba :
> >>
> >> On 2020-10-05 23:17, Azamat Hackimov wrote:
> >>
> >>>>> Is there a slotmove that can be applied?
> >>>>
> >>>> I am afraid I do not understand the question. What do you want to move,
> >>>> and why?
> >>>
> >>> Currently portage is mostly lua:5.1 aware and the first thing is move
> >>> dev-lang/lua:0 to 5.1 slot by slotmove in profiles/updates:
> >>>
> >>> slotmove dev-lang/lua 0 5.1
> >>
> >> The file structure of dev-lang/lua:0 differs from dev-lang/lua:5.x,
> >> meaning that introducing such a slot move would require Lua eclasses to
> >> treat lua5-1 differently from other targets. In other words, we would
> >> *still* need lua0 support but without a clearly distinct name.
> >
> > So there will be a new stabilized lua:5.1 version as I proposed.
> > Again, here is a quick todo list:
> >
> > 1. slotmove dev-lang/lua
> > 2. Change all dependencies to change from lua:0 to lua:5.1
> > 3. Stabilize & unmask slotted version 5.1.5-r103
> > 4. Release news & rebuild with emerge -a --oneshot $(equery depends
> > dev-lang/lua | awk '{print " ="$1}')
>
> Please don't use 'equery depends' for such things.  It shows what *can*
> depend and not what *actually* depends on a given system because of
> metadata shortcuts. (It won't consider USE for example.)
>
> If a library name is moving, the best tool is revdep-rebuild with the
> --library option with the old soname to look for.
>
> Brian

Depend packages can not use a library for linking, so it may be hard
to retrieve the actual list with revdep-rebuild.


--
>From Siberia with Love!

Re: [gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua

[Azamat Hackimov]

вт, 6 окт. 2020 г. в 15:04, Marek Szuba :
>
> On 2020-10-05 23:17, Azamat Hackimov wrote:
>
> >>> Is there a slotmove that can be applied?
> >>
> >> I am afraid I do not understand the question. What do you want to move,
> >> and why?
> >
> > Currently portage is mostly lua:5.1 aware and the first thing is move
> > dev-lang/lua:0 to 5.1 slot by slotmove in profiles/updates:
> >
> > slotmove dev-lang/lua 0 5.1
>
> The file structure of dev-lang/lua:0 differs from dev-lang/lua:5.x,
> meaning that introducing such a slot move would require Lua eclasses to
> treat lua5-1 differently from other targets. In other words, we would
> *still* need lua0 support but without a clearly distinct name.

So there will be a new stabilized lua:5.1 version as I proposed.
Again, here is a quick todo list:

1. slotmove dev-lang/lua
2. Change all dependencies to change from lua:0 to lua:5.1
3. Stabilize & unmask slotted version 5.1.5-r103
4. Release news & rebuild with emerge -a --oneshot $(equery depends
dev-lang/lua | awk '{print " ="$1}')
5. Now we have lua:5.1 portage ready to lua.eclass migration
6. PROFIT

1-4 can be done with one git push

-- 
>From Siberia with Love!

Re: [gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua

[Azamat Hackimov]

пн, 5 окт. 2020 г. в 22:20, Marek Szuba :

> > Is there a slotmove that can be applied?
>
> I am afraid I do not understand the question. What do you want to move,
> and why?

Currently portage is mostly lua:5.1 aware and the first thing is move
dev-lang/lua:0 to 5.1 slot by slotmove in profiles/updates:

slotmove dev-lang/lua 0 5.1

and update all ebuilds with dev-lang/lua:0 dependency (there are about
200 ebuilds with that dependency, maybe there need to be an issue news
item, since there may need to rebuild all dependencies).
After that we need to unmask and stabilize "true" slotted lua:5.1
version, so this would be step 0 on slotted lua migration. After that
migration of rest packages to new lua.eclass will be a lot easier.

> > I think a better idea is to migrate the base set of lua packages
>
> Define "base set of lua packages".

Well, core build ecosystem of lua packages:

dev-lua/ldoc
dev-lua/lpeg
dev-lua/luacov
dev-lua/luacrypto
dev-lua/luadoc
dev-lua/luarocks
dev-lua/luasystem
dev-lua/lua-utf8
dev-lua/lua-zlib

maybe more.

-- 
>From Siberia with Love!

Re: [gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua

[Azamat Hackimov]

Hi.

пн, 5 окт. 2020 г. в 21:01, Marek Szuba :
>
> I have decided to add support for dev-lang/lua:0 because having thought
> quite a lot about the transition path from Lua ebuilds as they are to
> the new eclasses, it seems to be the most sane approach. Still, I hope
> this will not stay around for too long.

Is there a slotmove that can be applied? Can be lua:0 and lua:5.1
coexist? Will there be more problems with that approach?
I think a better idea is to migrate the base set of lua packages to
slotted Lua (maybe under package.mask) and slowly migrate the rest of
the portage.

-- 
>From Siberia with Love!

Re: [gentoo-dev] Last rites: next batch of py2 packages

[Azamat Hackimov]

Hello.

сб, 19 сент. 2020 г. в 15:51, Michał Górny :
> sys-firmware/nvidia-firmware
>
Created PR https://github.com/gentoo/gentoo/pull/17600

-- 
>From Siberia with Love!

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

[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

[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

[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

[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

[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

[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

[Azamat Hackimov]

> games-emulation/openmsx

git version migrated to meson and python3

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

[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

[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

[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

[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

[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

[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?

[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

[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

[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

[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!