[gentoo-dev] Last rites: www-plugins/gosuslugi-plugin

[Vadim A. Misbakh-Soloviov]

# Vadim Misbakh-Soloviov  (2024-02-22)
# Masked for removal in 30 (or more) days.
# Fetches only from specific geo-locations, hostile upstream, security issues.
# Consider to use the version from overlay named "mva" after tree-cleaning.
# No revdeps.  Bug #876271
www-plugins/gosuslugi-plugin   


-- 
Best regards,
mva

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

[gentoo-dev] Packages up for grubs: media-libs/vitamtp, app-misc/qcma, sys-power/bbswitch, www-plugins/gosuslugi-plugin

[Vadim A. Misbakh-Soloviov]

Hi there!
I've decided to step over from some packages I maintained before due to lack 
of time, competence, and in case of one of them - phisical ability for 
resolving corresponding issues.


Packages available for grabbing includes:


media-libs/vitamtp
app-misc/qcma


^ That two packages are essential to work with PS Vita (manage its library, 
transfer applications and so on).
Unfortunately, I had lost my Vita, so have no more motivation in maintenance 
of that packages. Also, one of them is archived by upstream and requires 
patching to support new ffmpeg.
And I have no competence in that, and, unfortunately, too busy at work to dive 
in this.

So, if you need them - feel free to take.
I'd be glad to help you with them (and, maybe, I can even be a proxy for you)



sys-power/bbswitch


Actually, there is still Pacho Ramos stays as direct maintainer, and there is 
also one proxied maintainer, but it would be nice if someone would also take 
care over it.

Actually, none of laptops I currently using have Optimus (actually, I have 
one, but there is long outdated gentoo, and I have no time to reinstall it to 
current state), so I have almost no hardware to work with this package 
anymore.

If you'd like to help @Pacho and @rei4dan with it, please, join them.



www-plugins/gosuslugi-plugin


Actually, this is a browser native-messaging pluginn (helper) for webextension 
for working with russian e-gov site(s).

Since... Uhm... Some time ago, upstream blocked access from foreign IPs 
(making it impossible to fetch the distfile)
Also, upstream is kinda hostile (uses unversioned tarballs, ignores any 
emails, also, package requires 777 on it's directory in /var/log (as it writes 
there a log when run under ordinary user, and I reported that more than two 
years ago already)).

Also, @sam nnoticed that gentoo repo is probably not a place for such 
packages, and I think I agree with him (although, I think I saw another 
countries e-gov related packages in the repo before)

So, I don't think this actually needs to be grubbed up (but who knows), so I'd 
just tree-cleaned it.


-- 
Best regards,
mva

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

Re: [gentoo-dev] [PATCH 01/15] dev-libs/tree-sitter-php: fix HOMEPAGE

[Vadim A. Misbakh-Soloviov]

merged to gentoo repo

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

Re: [gentoo-dev] [PATCH] dev-libs/tree-sitter: support for building cli tool

[Vadim A. Misbakh-Soloviov]

merged to gentoo repo

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

Re: [gentoo-dev] [PATCH] eclass/tree-sitter-grammar: fix ABI autodetecton

[Vadim A. Misbakh-Soloviov]

Merged to gentoo repo

-- 
Best regards,
mva

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

Re: [gentoo-dev] [PATCH] eclass/tree-sitter-grammar: fix ABI autodetecton

[Vadim A. Misbakh-Soloviov]

oops, forgot `v2` in subject.

Added it all the time during pre-send tests, and missed when sent it for real

:facepalm:

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

Re: [gentoo-dev] Experimental binary package hosting

[Vadim A. Misbakh-Soloviov]

Finally it happened!

I already planned to try to ask infra/council about sponsoring few servers for 
build farm for "official gentoo binhosts" when I had enough time, but 
fortunately, you've already did that.

It's very good news.

Btw, do you need any help with that?

I'd be very happy to help with that project.

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

[gentoo-dev] Re: sys-power/bbswitch up for grabs

[Vadim A. Misbakh-Soloviov]

В письме от суббота, 26 декабря 2020 г. 20:22:33 +07 пользователь Piotr 
Karbowski написал:
> Hi,
> 
> I've been maintaining sys-power/bbswitch in the recent times, however, I
> no longer have any hardware where I can even test it. If anyone sees it
> fit, feel free to grab it and join other maintainers there. I just
> dropped myself out of metadata.xml.
> 
> Open bugs:
> - https://bugs.gentoo.org/761370
> - https://bugs.gentoo.org/613338
> 
> -- Piotr.

Actually, I've also almost no Optimus hardware ATM. Maybe, I'll drop myself 
from metadata too

-- 
Best regards,
mva

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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Vadim A. Misbakh-Soloviov]

> Modification of system users and groups are also covered by that user.

fix: <...> by that rule.

-- 
Best regards,
mva

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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Vadim A. Misbakh-Soloviov]

> 
> And now you're changing the subject.  You've just claimed that *your*
> user's group ownership will be overwritten and when challenged you
> present the case of *system* user's group ownership being overwritten.

Actually, he showed the rewrite of **system** user (that was modified 
locally).

And, as it already mentioned above, this behaviour violates Gentoo Philosophy 
of not pretending to be smarter than user and don't dictate them a way to go.

So, if the problem is only in the existance of the bug, I can create it 
tomorrow morning.
But it would be great to know that it wont be closed in a minute after with 
"WONTFIX, works as expected".

Also, as already stated, changing the stuff that was modified by user is 
**prohibited**.

P.S. I don't care about your  relations with whissi, but let's back to the 
topic:

[big red letters]
We should **NEVER** ever rewrite any system configuration made by local system 
administrator (call it "user" or whatever). Dixi.
[/big red letters]

Modification of system users and groups are also covered by that user.

So, we, actually don't need any changes to disable acct-* things at all and 
make users to manage all the things by themselves.
We need a change that will prevent any changes over **already existing** user.

I think we should make it in a manner like:
1) when we install acct-pkg for a first time - CONFIG_PROTECT changes, and let 
user to review.
2) when we **reinstall** same package - do **nothing**. Although, I'm not sure 
here:
on the one hand, why should we bother users by merging changes they already 
did before,
on the other hand, it can be useful way to reset to defaults in case if "all 
this stuff is screwed up".
3) when we upgrade acct-package (assuming there was changes) - only allow 
"positive" changes (group additions), but not negative (dropiing groups), and 
anyway CONFIG_PROTECT all the changes.


Well, there is also "kludgy way": does not globally reimplement anything, but:
1)  force CFGPROTECT
2) perform a "light" modification to only perform "positive" modifications 
(see above) on users/groups, but no "negatives".
It will anyway fix the both issues Whissi and OP had. 

-- 
Best regards,
mva

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

[gentoo-dev] [RFC] New eclass patches.eclass

[Vadim A. Misbakh-Soloviov]

HI there!

Some time ago I invented patches.eclass, which facilitates my work with 
patches, and I would like you to express your opinion about it and whether it 
is worth committing in gentoo repo.

Maybe it’s even worth it to become a helper, but not an eclass, or be bundled 
somewhere in existing eclasses/helpers.

-- 
Best regards,
mva# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

# @ECLASS: patches.eclass
# @MAINTAINER:
# mva
# @AUTHOR:
# mva
# @BLURB:
# @DESCRIPTION:
# Eclass that checks for patches directories existance and auto-add them into 
PATCHES=()

EXPORT_FUNCTIONS src_prepare


patches_src_prepare() {
[[ -z ${PATCHES[@]} ]] && PATCHES=()
PATCHDIR_BASE="${FILESDIR}/patches"
PATCHDIRS=("${CUSTOM_PATCHDIR:-non-existant-dir}" "${SLOT//\/*}" 
"${PV}" "${PV}-${PR}")
for PATCHDIR in ${PATCHDIRS[@]/#/${PATCHDIR_BASE}/}; do
if [[ -d "${PATCHDIR}" ]]; then
_patchdir_not_empty() {
local has_files
local LC_ALL=POSIX
local prev_shopt=$(shopt -p nullglob)
shopt -s nullglob
local f
local lvl=${2}
for f in "${1:-${PATCHDIR}}"/*; do
if [[ "${f}" == *.diff || "${f}" == 
*.patch ]] && [[ -f "${f}" || -L "${f}" ]]; then
has_files=1
elif [[ -d "${f}" ]] && [[ "${lvl:-0}" 
-eq 0 ]]; then
# limit recursion to first 
level only,
# since eapply cannot into 
recursion,
# while 2-lvl "conditional" 
patching implemented below
let lvl+=1
_patchdir_not_empty "${f}" 
"${lvl}" && has_files=1
fi
done
${prev_shopt}
[[ -n "${has_files}" ]]; return $?
}

_patchdir_not_empty && PATCHES+=("${PATCHDIR}")

if [[ -d "${PATCHDIR}/conditional" ]]; then
pushd "${PATCHDIR}/conditional" &>/dev/null
for d in *; do
if [[ -d ${d} ]]; then
if [[ "${d##no-}" == ${d} ]]; 
then
(use "${d}" && 
_patchdir_not_empty "${d}") && PATCHES+=("${PATCHDIR}/conditional/${d}")
else
(use "${d##no-}" && 
_patchdir_not_empty "${d}") || PATCHES+=("${PATCHDIR}/conditional/${d}")
fi
fi
done
popd &>/dev/null
fi
fi
done
if declare -f cmake-utils_src_prepare &>/dev/null; then
# cmake-utils_src_prepare support (to decrease kludges in the 
ebuilds)
cmake-utils_src_prepare
else
default_src_prepare
fi
}


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

[gentoo-dev] Re: [gentoo-dev-announce] Last rites: net-analyzer/zabbix

[Vadim A. Misbakh-Soloviov]

I'm using zabbix, but I can't sign up as the single active maintainer, 
although, I'd be happy to co-maintain it with somebody else.

BTW, @mgorny, as I see, Patrick already fixed the issue, so can we talk about 
unmasking and un-lastriting zabbix now? 


-- 
Best regards,
mva

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

Re: [gentoo-dev] Deja vu

[Vadim A. Misbakh-Soloviov]

В письме от вторник, 5 ноября 2019 г. 00:14:34 +07 пользователь Michael 
Orlitzky написал:
>   * Error: The above package list contains packages which cannot be
>   * installed at the same time on the same system.

Check the ebuild version stored in /var/db/pkg :D

[gentoo-dev] Sorry for irrelevant messages

[Vadim A. Misbakh-Soloviov]

Hi there!

I'm sorry for the spamming few lists with irrelevant messages few miuts ago.

I just re-subsribed to all the lists with @gentoo.org address (instead of 
personal), and then confirming all the subscribtions with "next+reply+send" 
shortcuts, and didn't stop at the correct time, so I also replied some 
"Welcome" emails too.

Sorry for that.

[gentoo-dev] Re: Welcome to gentoo-dev@lists.gentoo.org

[Vadim A. Misbakh-Soloviov]

В письме от воскресенье, 3 ноября 2019 г. 23:01:43 +07 пользователь gentoo-
dev+h...@lists.gentoo.org написал:
> Thank you for confirming your subscription. You have now been added to the
> normal version of the list.
> 
> The email address you are subscribed with is .
> 
> If you ever wish to unsubscribe, send a message to
>  using this email address. The
> subject and the body of the message can be anything. You will then receive
> confirmation or further instructions.
> 
> For other information and help about this list, send a message to
> .

Re: [gentoo-dev] [RFC] C++ standard in ebuilds

[Vadim A. Misbakh-Soloviov]

I'd prefer to wait another replies on the list for the main theme of this e-
mail, but this problem also affects C (so, as **c**flags and C standards), so 
solution shoudn't be c++ specific, imho.

Re: [gentoo-dev] [PATCH] systemd.eclass: set BDEPEND for EAPI 7

[Vadim A. Misbakh-Soloviov]

В письме от понедельник, 6 августа 2018 г. 22:13:49 MSK пользователь Ulrich 
Mueller написал:
> > On Mon, 6 Aug 2018, Mike Gilbert wrote:
> > -DEPEND="virtual/pkgconfig"
> > +if [[ ${EAPI} == [0123456] ]]; then
> 
> This should use ${EAPI:-0} because for EAPI 0 the variable can be
> empty.
> 
> > +   DEPEND="virtual/pkgconfig"
> > +else
> > +   BDEPEND="virtual/pkgconfig"
> > +fi

And how about "-le"/"-lt"/"-ge"/"-gt"/"-eq" syntax?
Or even ((EAPI<7))?
Are they forbidden to use in eclasses?

Anyway, I think, it is possible to add something like "EAPI=${EAPI:-0}" 
somewhere at the top of eclass, to don't call "${EAPI:-0}" each time when EAPI 
variable is needed.

Re: [gentoo-dev] rfc: moving default location of portage tree

[Vadim A. Misbakh-Soloviov]

> I guess /var/portage is not  a terrible choice.

Well, I double that.
I've already use the following structure:
|- /var/portage/
|   |- repos
|   |   |- gentoo
|   |   |- reponame1
|   |   |- reponame2
|   |- distfiles
|   |   |- ...
|   |   |- ...
|   |- packages
|   |   |- ...
|   |   |- ...
|   |- meta
|   |- layman
|   |- ... # (used to be used for layman stuff until 
eselect-repository)


And I think it's pretty fine and usefull, especially because distfiles/
packages does not belong to one specific repo (gentoo) as it does with /usr/
portage.

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

[Vadim A. Misbakh-Soloviov]

Well, in *my* opinion, in turn, having possibility to {R,}DEPEND on package 
from exact repo is much and much more needed functionality.

Say, I have pkg2 in my repo, that depends on pkg1, which is in my repo too.
Then, I (or user) add other repo having pkg1 too. Or, say, gentoo maintainers 
bump pkg1 to a newer version (while I'm slacking a bit).
And my pkg1 is a bit different from gentoo's (let it be patchset, or, say, 
lua.eclass support for lua overlay).

So, that changes results in random unexpected behaviour as blocks, runtime 
breakage and so on.

And renaming all the packages to not collide with gentoo/other repos naming 
is, well, not an option, I think.


Or, another example:
I making pkg4 in my repo1, which depends on pkg3 from repo2 (where I 100% sure 
it fits all the requirements and the patchsets), while pkg3 in ::gentoo 
doesn't (and it can even have a bug about that opened for a century already).

Currently, it is no way to say "only dep-pkg from that exact repo is 100% 
works as expected", so there is still the chance, that someday pkg4 would fail 
to build because suddenly pkg3 was reinstalled from another "incompatible" 
repo...
And, honestly, current ways to resolve that issue (adding dummy-useflags, 
copy_here, and so on) looks as very dirty hacks.

Re: [gentoo-dev] Re: How to deal with git sources?

[Vadim A. Misbakh-Soloviov]

> Perhaps they refer to .zip instead of .tar.gz which as mentioned is
> a less stable format due to the inclusion of the timezone.

Nope. I myself also faced tarballs checksum difference (even between few 
calls).

GH support answered me (in TL;DR version) "that's because we've upgraded git 
on *some* of our nodes" (means, some other using older git), and "we've never 
guaranteed same checksums".

Re: [gentoo-dev] Questions on overlays, repositories and PMS

[Vadim A. Misbakh-Soloviov]

> Or in other word, it is enough to only look at /etc/portage/repos.conf?
No

> In general, an overlay is a repository, i.e., a valid tree layout for the
Yes
 
> - can the profiles in a repository different from DEFAULT be selected?
Yes

> - is the package.mask file apply only on the packages of that repository, or 
> on every packages of
> every repositories listed in /etc/portage/repos.conf?
Actually, I can't remember the correct answer right now, but definitelly it 
have the effect on repos, that states this repo as master.

> is such information implicitly inherited from the DEFAULT repository (even
> though https://wiki.gentoo.org/wiki//etc/portage/repos.conf states that it
> is not)?
Usually, that info is inerited from `master` repo of the current repo (that is 
stated in the layout conf file)

> the brother overlay (https://github.com/stefan-langenmaier/brother-overlay) 
> does not specify
> any masters
Eeeerm?
https://github.com/stefan-langenmaier/brother-overlay/blob/master/metadata/layout.conf#L1

> - when the eclass folder, profiles/arch.list and such are
> present, is the data from the DEFAULT repository still implicitly
> inherited?
I still insist on inheritance from master repo.

> - when the eclass folder, profiles/arch.list and such are
> present, are they visible globally (i.e., a package from another repository
> can use a keyword of the arch.list and inherit from one of the eclass)?
AFAIRC, depends on the repos relative priority.

> 4. is the "masters" attribute in /etc/portage/repos.conf make the repository
> inherit other data than the eclasses?
Yes, but that attribut is usually not recommended for general use.

> 5. since every repos can have a profiles/categories file, is the file
> /etc/portage/categories obsolete (or should it be)?
Why?

Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

[Vadim A. Misbakh-Soloviov]

And it would be nice to also recall the overlays, which can also use repoman 
(and/or mgorny's travis hook for that), but at the same time have no 
possibility to self-host the patches...


// well, I personally would prefer that repoman had an option to "ignore" some 
(specified as an argument) of the QA issue types, and have no objections on 
32k limit.

Although, I also like the idea to just move all patches to gentoo-infra-hosted 
hosting (if it will be possible for contributors to use it, but not only for 
devs), like it was mentioned before.

Re: [gentoo-dev] Last Rites: Ancient x11-drivers/*

[Vadim A. Misbakh-Soloviov]

> > x11-drivers/xf86-video-modesetting
> 
> Please keep this one for the generic KMS case. It's been useful.

For now, it ships inside xorg-server since at least few versions already...

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

[Vadim A. Misbakh-Soloviov]

В письме от понедельник, 16 октября 2017 г. 13:42:05 +07 пользователь Azamat 
Hackimov написал:
> Github creates tarballs for tags automatically, for 1.3.0 tag it would be

There is go eclasses for that, and I guess OP wanted advice about some go-
eclasses magic for that.

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

[Vadim A. Misbakh-Soloviov]

> Well, I'd argue the case for "not 'perfectly'", because for better or for
> worse, systemd has had rather more luck at cross-distro init-system
> unification than that comic suggests.

It would have a chance to be true if systemd had less stupid bugs (which never 
appeared in other init systems), don't ignore CVEs and support custom actions 
on units.

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

[Vadim A. Misbakh-Soloviov]

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?


P.S. actually, it also would be nice to add "generators" thing to it too, to 
make it possible to manage services that have no systemd's units under SystemD 
and services that have only units under OpenRC (well, that one looks much 
harder than first variant, but, again, looks like deb/ubuntu guys did that 
work already and we can try to use their work as cheatsheet)

Re: [gentoo-dev] [RFC] New eclass vim-runtime

[Vadim A. Misbakh-Soloviov]

DEPENDS part and "binary" function makes me sad panda:
they assumes there are no "vims" exist, while there is at least `vim-qt` 
(well, actually that one is dropped from gentoo) and `neovim-qt` (and that one 
is in overlays, but anyway), and so on.

I think, it'd be nice to somehow avoid exact binary names matching (just as 
exact package names), or, uhm... make it extendable somehow?

Re: [gentoo-dev] Need GitHub snapshot hash verification failure samples

[Vadim A. Misbakh-Soloviov]

By the way, that is "known issue" on github (I already discussed that with 
their support even few years ago). The answer was kinda "well, it can happen 
time to time, since we can upgrade software like tar and/or git on some or all 
of our servers and we never declared tarballs checksums similarity".

So, even if somebody will trigger that once more, I doub't github support will 
answer something different this time.

Re: [gentoo-dev] lua upgrade plan

[Vadim A. Misbakh-Soloviov]

By the way, it will also brake some proprietary games, that distributes via 
steam, humble, gog and so on.

Some of them depends on shared lua and doesn't bundle it (instead, their 
installer calls apt (since they're doing games for ubuntu), but since we have 
no apt, we (gamerlay/games team) just writing proper DEPENDs, unpacking the 
content, and installing it.

So, if shared lua will be dropped, we will either have a bunch of broken games 
or used to create some kludgy "lua-shared" custom ebuild, which is worse way 
of doing the things.

So, I'm voting for status quo. 

Re: [gentoo-dev] lua upgrade plan

[Vadim A. Misbakh-Soloviov]

> excellent LuaDist
I'd not say it is excellent :( I'd rather say "NIH-syndromed"

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

Well... Actually, it does. In Lua overlay. But mgorny (?) had a bunch of 
critics about it, so I just keeping it in Lua overlay and not proposing it to 
the gentoo repo anymore (I just have not enough time to rewrite it in the way 
it will pass mgorny's review :).

Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream

[Vadim A. Misbakh-Soloviov]

> I welcome feedback.

And how about KSPP and other similar projects, that tries to continue the idea 
of community-friendly development based on latest release available to wide 
public (or, maybe some other, that was grown in parallel with PaX)?




[OFFTOP]
I personally very dislike Brad's behaviour.
Not only closing the source from public.
Not only blackmail to ban from updates for customers that will public the 
patches.
But also his trolling against KSPP:
Firstly he cried they steal his work (yup, steal. OpenSource. Lol).
Then he stated that he wants that KSPP stated *both* that their work is based 
on Grsec *and* that they have no connection with grsecurity at the *same 
time*.

So, it looks like he does not really care about Linux Security. He only cares 
about his business.
Which is against my vision of opensource community principles.
So, since that time I have no non-offensive words to describe him anymore.

So, I previously decided to take latest available hardened-sources patchset 
and maintain it (mostly, fix for new kernel releases) locally for my needs, 
until Gentoo Hardened will migrate to KSPP, or KSPP will merge all of the work 
into "vanilla" Linux.

But since I read this notice, I'm very sad about the destiny of Gentoo 
Hardened. It was the best solution for production servers, imho. But news like 
that makes people think that it (Hardened Gentoo) starts pre-death agonia. And 
that's very and very sad :'(
[/OFFTOP]

Re: [gentoo-dev] last rites: app-text/acroread

[Vadim A. Misbakh-Soloviov]

> media-fonts/acroread-asianfonts

Is it also due to security issues? :D

Re: [gentoo-dev] Last rites: www-apps/postfixadmin

[Vadim A. Misbakh-Soloviov]

Well, actually, I think that whole webapps structure in gentoo should be 
dropped or totally rewritten, despite of web applications packages state in 
the gentoo repo.
It is unextendable, uncomfortable, no-gentoo-way'ish and so on.

I think, it would even be better to just install apps in /usr/share/${PF} than 
current webapp behaviour.
 

And, talking ontopic, I think let it (postfixadmin) be dropped.
Anyone interested (like me) will just fetch tarballs directly from upstream, 
and upgrade in usual way, without webapps black magic and sacrificing virgins.

Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist

[Vadim A. Misbakh-Soloviov]

> Can phantomjs be simply masked for a longer period until the development
> world has had an opportunity to catch up?

Just exactly what I thought.

Although, in-tree version is obsolete anyway, and upstream made few next 
releases with brain-exploding buildsystem, so I just pushed  version to my 
"public sandbox" overlay, and happy with it on the projects that depends on 
phantomjs.

By the way, headless chrome, well, work a bit different in comparsion with 
"analogs" (including wkhtmlto{img,pdf}), so, it needs much more time than a 
month to get full analogs.

So, I'm disagree with monthly dropping in this context too (well, I disagree 
with the idea. As I just said, I by myself is in safe from being affected by 
it).

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Vadim A. Misbakh-Soloviov]

> strongly against eselect modules (and any user code) that
> writes into /usr (except for /usr/local)

Well, NeoVim, at least, have support for site-dir in /usr/local out of the 
box. I guess, Vim8 will need a bit of patching for that.

Although, I'm, in opposite, dislike (very little, tho) /usr/local, since it 
makes me feel like FreeBSD'er.

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

[Vadim A. Misbakh-Soloviov]

> libfoo-debug

Shouldn't we mention "debug" USE-flag in this context somehow?

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Vadim A. Misbakh-Soloviov]

1) Dear Vim Team, can we hear your opinions?

2) I'd like to know if discussion participants really differs my eselect-php-
like suggestion (where all scripts goes to another directory, controlled by 
neither of vims, and then users should/can manually dis-/enable modules for 
each of vim they want) from Ciaran's suggestion of making a directory common 
for all vims, patch all the vims, and force *developers* to check modules and 
put them there only after check modules under both (currently) vims (as side 
effect leave neovim users without modules until developers finaly finish that 
work).

And what point they (participants) really supports?

3) Again, dear Vim Team, please come here, and take a part in the discussion.

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Vadim A. Misbakh-Soloviov]

> - Have a separate anyvimishthing directory, and make both vim and
> neovim look there, and only make plugins that have been tested to work
> with both install to that directory.

Actually it is almost the thing I described as "second" eselect variant.
Although, you suggest for gentoo devs to check modules work (and we're all 
know that it can take eternity), while I suggest to give users a tool to rule 
that on their own.

[gentoo-dev] [RFC] NeoVim and vim-syntax

[Vadim A. Misbakh-Soloviov]

Currently, we have a situation, that there are two Vim's: "old" one (vim8) and 
NeoVim (for those who do not know: a fork of Vim with much and much more clean 
code, many neat features and so on).

Unfortunately, both of them have different runtimedirs: XDG ones for NeoVim 
and the ones you know for Vim8, while NeoVim is fully compatible with Vim's 
plugins, and epecially with vimscripts (like syntax definitions and ftdetect 
scripts).

On the other side, we have a bunch of packages in the portage tree, that have 
"vim syntax" support (use-flags, or direct vim-syntax packages), or even vim-
plugins.
All of them goes to `/usr/share/vim/vimfiles`, while correct path for NeoVim 
would be `/usr/share/nvim/site` (does not exist at the moment, but nvim checks 
for it).

So, that situation leads to impossibility to get all of that syntax definitions 
and plugins when user uses NeoVim.

As I said above, NeoVim supports Vim's plugins/scripts very well (although I 
didn't find any evidence of the opposite), so it is possible to fix that 
situation by many of "kludge" ways, including:

- implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all the 
installed files

- patching NeoVim source to include Vim's runtimedirs (incl. "after" dir),
// NeoVim upstream highly disagree with such way, if any

- patching VIMRUNTIME environment variable,

- making a wrapper,

- rewrite all the existing ebuilds to take nvim into account and force all 
newcomers to also take it,

- symlinking a directory,
// mostly bad way, since opposite plugin compatibility is not garanteed and 
users can install nvim-only plugins in the future

- making postinst hook to regenerate content of NeoVim's site-directory 
(maybe, by symlinking installed vim modules there)

or even:

- making eselect module for user to rule that.

Although, talking on eselect module, I've two visions of the situation:
a) it can be something like bashcomp module, where users can select which of 
installed vim modules they want to "enable" in NeoVim
or (better, imo) way:
b) it can be something like php module, where portage installs all the stuff 
in the location neither available to Vim nor NeoVim, and users selects which 
modules they enable for either implementation.

Module can be called something like "eselect-vim" or "eselect-vim-modules" 
(?), if any.


For now, I have preview of neither of eselect module variants, nor even 
patches for another "ways". I'd very like to discuss the situation and find a 
better of possible solution first.
Maybe, when (if?) we found such a solution, I'd contribute a PR with it on GH.

--
wbr,
mva

Re: [gentoo-dev] Reverse use of Python/Ruby versions

[Vadim A. Misbakh-Soloviov]

Also, 

> Its an update issue. You set a target to say Ruby 24. But something
> wants Ruby23. It could be it only builds with ruby23. Or more than
> likely no one has gotten around to adding it to the package. Since for
> every new version. EVERY ebuild must be touched.

As I said above, this only happens if package manintainer is a slacker and a 
package wasn't touched for years.

Chances that it will work with new ruby is... about 0%. Why should you auto-
add modern ruby targets for it then?

Instead, you should blame package (that causes regression) maintainer and/or 
take maintenance in your hands (if you need that package), or just drop it 
from your system (if not).

// Although, it is another question to discuss:

Most of time in such situations (with ruby crap mess, lol) Portage is unable 
to tell which exact package is guilty in all that crap (even with --verbose-
conflicts --backtrack=100500 and so on) and you need to mask old rubys and re-
run world-upgrade to catch the one who fails because of mask. I agree that it 
is not expected portage bahaviour, but I have not done deep research to write 
detailed report and suggest a solutions for this problem, abd just reporting 
it was useless, since, predictably, nobody cares (everybody ok with this).

That ^ is the point to discuss. But I disagree that '>=foo-1 <=foo2' stuff 
should be used instead of targets.

Re: [gentoo-dev] Reverse use of Python/Ruby versions

[Vadim A. Misbakh-Soloviov]

> or PHP.

Wouldn't you be so kind to re-check this part, please? :)

Re: [gentoo-dev] Reverse use of Python/Ruby versions

[Vadim A. Misbakh-Soloviov]

Am I right in assumption that you arguing about *_TARGETS rework to be enabled 
by default for packages that was not tested on this TARGETs with ... hardness 
of packaging java software?..

Or does it just argmentum ad verecundiam (with argumentum ad hominem 
partially)?

And yes, I personally packaged Java software from scratch (including all the 
depends).

And yes, some times I even thought "F**k this sh*t!" (but finished packaging 
afterwards).

And yes, I packaged Go software.

And yes, I packaged NodeJS software.

And no, they are NOT much easy to package then Java one (even including they 
still have no TARGETS... As java? :D).

But how does it apply to TARGETS logic breakage?

The purpose of TARGETS is that package holds only that TARGETs that it was 
tested to work against. It is wrong to have any targets enabled by default for 
all the packages and removing in case if it is broken. Instead, if new target 
appeared a month (year, decade) ago, but package, that you're interested in, 
still doesn't support it... Well.. It meant, maintainer is a slacker and 
package is a candidate to last-rites and removal...

Re: [gentoo-dev] News item: app-emulation/wine split and slotting

[Vadim A. Misbakh-Soloviov]

> package wine-foo and  wine-any (or whatever it is called) supports foo
> as well.  "-any" itself is arbitrary.  Do you have a suggestion for a
> better suffix?

Why don't leave that "any" package just "wine" as it was before?..

Re: [gentoo-dev] Reverse use of Python/Ruby versions

[Vadim A. Misbakh-Soloviov]

> painless option for users.

Well... If a bit of mind work is pain... So, then I'd say that Gentoo is not 
about avoiding such pain.

Did you hear about Gentoo Philosophy?

It says that point of Gentoo to appear was to give users possibility to make 
exact "tool" they wants to use, but not decide anything for them.

So, if a person wants to avoid thinking about some aspect of the system 
maintenance, then Gentoo is not recommended for this person and the person 
should consider to use some distro made by "Big Fat Corporations" (like 
Ubuntu, Fedora/RHEL, SuSE and whatever). They're very like to dictate what and 
how should user do, and what should not. And there is all that things already 
decided by BigBro's and users should not take care of any of that.


I can't understand people who refuse to get as complete knowledge as possible 
about tools/instruments they using (including OS).

Would you learn how does a hammer work before applying it to the nails? Or do 
you say "The only painless option for users is to make it spheric" instead?

And same for Gentoo: if you want to use something — please, consider to get a 
bit knowledge about how do it working. And it will be huge karma bonus for 
you, if you'll research the reasons why did it done in that way, and not 
another before complaining (why did wheels invented to be round, but not 
square? Square wheels are more stable on a flat surface, while round ones 
makes wagon to constantly move, while I loading my baggage on it).

I mean: most of the time, if you having trouble with something, it is most 
likely *you* (not you personally, but some abastract Freud-ish "you") doing 
something wrong, then the tool you're using is badly designed. And if you 
dislike the tool's design, you're free to take analogous tool from the rivals 
(and take that one you'd like).


Thanks for attention,
wbr, mva

Re: [gentoo-dev] Reverse use of Python/Ruby versions

[Vadim A. Misbakh-Soloviov]

> If Java can do it, so can others.

And here I come with my 5¢. And my point here is simple:

No, Java (Team) can't.



Every time I come to Java team with some report they suggest (as joke, 
partially) to become a "full" developer (but not a contributor) and take care 
of this by myself.

And they never fixed the reported issue in less than few month.

And even if I doing a PR, it can take an eternity to be merged.

It looks like their infrastructure is so brainf**ing, that they prefer to 
slack instead of doing maintenance.

I asking excuse of every Java team member, if my words hurt any one of them, 
but that is just my vision of the situation.

Re: [gentoo-dev] [RFC] New Manifest hashes and how to enable them

[Vadim A. Misbakh-Soloviov]

> What is the gain of using a secure hash
> algorithm in the manifests if you can simply replace the manifest with a
> MITM attack on the rsync update?

I'd say "the solution is to stop using rsync and use git" (there is git mirror 
with all the metadata), but...
Git does not support (correct me, if I'm wrong) resuming a fetch in case of 
fails (bad connection, slow connection, or the any other reason to stop it and 
continue later).

So... We either need GPG manifest signing enabled, or totally move to git and 
ignore all the users with bad internet connection and totally move portage to 
git (hint: we shouldn't), until we invent something else, that can solve all 
of that problems.

Re: [gentoo-dev] [RFC] New Manifest hashes and how to enable them

[Vadim A. Misbakh-Soloviov]

Good idea, but all the time I read it from first mention until the end of your 
email, I asked myself: "Who the hell on the Earth need GOST-crypto crap in 
portage?".

The only purpose of this crypto algorythms is to use them in Russian 
government-related structures (includig schools, tho :-/ ) just because of 
"security through NIH-syndrome".

So, does it mean, gentoo was (or have plans to be) certified by FSB to be 
"Russian national OS", or how is it possible on Earth that GOST algos was 
implemented in portage? :)



So, excluding this moment, I voting up for your suggestion ;)

Re: [gentoo-dev] bzipped manpages

[Vadim A. Misbakh-Soloviov]

В письме от вторник, 10 января 2017 г. 13:08:14 +07 пользователь Jan Stary 
написал:
> On Jan 10 19:04:47, gen...@mva.name wrote:
> > > There is an option to support; the packages need to be reinstalled
> > > or there are untracked files; the manpage formatter needs to call
> > > external unpackers. All this to save 40M. I honestly don't think
> > > it's worth it.
> > 
> > Why do you care about calling external unpacker,
> > but do not care about saving 40MB?
> 
> Because not having to call an external unpacker
> allows for the manpage formatter to be simple;
> whereas saving 40M of space is of no concern.

You arguing that 40MB is nothing on modern systems (which, by the way is not 
exactly true, talking about embedded ones).
So, I guess, it means, that you have modern powerfull hardware, which is 
pretty fine with some overheads.

Then why do you need "simple" manpage formatter? Why don't use all of that 
complicated ones (man-db, vim's Man.vim, whatever) instead?

P.S.:

And actually, why calling external unpacker is so complicated? Almost any 
programming language I know, has functions identical to C's system()...

P.P.S:

Do you fully understand, that you asking to change "defaults", that will 
affect tons of users (which are happy with current "defaults") because yours 
only own local problems (not having root access on the system)?

Re: [gentoo-dev] bzipped manpages

[Vadim A. Misbakh-Soloviov]

> There is an option to support; the packages need to be reinstalled
> or there are untracked files; the manpage formatter needs to call
> external unpackers. All this to save 40M. I honestly don't think
> it's worth it.

Why do you care about calling external unpacker, but do not care about saving 
40MB?

Double standards?

Re: [gentoo-dev] News item: KDE Workspaces 4.11 and KDE profile removal

[Vadim A. Misbakh-Soloviov]

> Display-If-Profile: <...>

How about arm64, amd64-fbsd and so on? :)

Re: [gentoo-dev] [rfc] New global USE flag: rbd

[Vadim A. Misbakh-Soloviov]

Shouldn't this
>> app-backup/bareos:rados - Enable rados storage backend
> storage backend
go to the first list?

Re: [gentoo-dev] RFC: global USE c++11

[Vadim A. Misbakh-Soloviov]

I bet it is not about ABIs, but about a vallue for '-std' flag for gcc/clang 
compiler. Some packages allows to select between -std=c++1{1,4,7} (and some - 
defaults with older ones otherwise).

Re: [gentoo-dev] Uppercase characters in package names

[Vadim A. Misbakh-Soloviov]

> We could make a more "user friendly" feature by setting up bash
> completion for package names, but that sounds a) daunting, b)
> error-prone, and c) probably not worth the time spent writing the
> script(s) necessary.

By the way, the ones for zsh is already done and working (even for sets).

Although, talking about main topic of the thread, I think that emerge lacks 
"autocontinue" support in cases, where there is only single variant of 
misspelled suggestion more, that requirement to name all packages lowercase :)

Re: [gentoo-dev] x11-misc/bumblebee and x11-misc/virtualgl up for grabs

[Vadim A. Misbakh-Soloviov]

By the way, as I was co-maintainerwith Pacho, and now my primary laptop is alo 
missing optimus (although, I still own few optimus-powered laptops, which I 
gave away to family members). So, not that I totally not interested in 
bumblebee anymore, but I can't fully maintain it.

So, can you (whoever will take all this stuff) also remove me from there 
(actually, from virtualgl, since I already not in bumblebee's metadata)?

But anyway, I am still opened for answering some questions about it and test 
something if needed.

And I'd also like to transfer bumblebee overlay ownership, if anyone is 
interested.

Re: [gentoo-dev] nftables

[Vadim A. Misbakh-Soloviov]

I tried to migrate my ruleset to nftables and fount that nft lacks all of non-
in-kernel xtables modules (see xtables-addons package) and even some of in-
kernel ones: https://wiki.nftables.org/wiki-nftables/index.php/
Supported_features_compared_to_xtables

Re: [gentoo-dev] Status of Lua in Gentoo

[Vadim A. Misbakh-Soloviov]

Please, consider to check lua overlay for all that problems.

And, talking on lua.eclass: I already posted it here for review, and mgorny 
said "kill it with fire" (because eclass was based on ruby-ng with some magic 
additions from python eclasses, perl ones and php. Well, it really is a bunch 
of black magic. And it definitelly need to be rewriten, but it takes much 
time, so I'd like to take some help.

And, talking on lua project, in the times of herds there was lua herd with 
mabi and rafaelmartins. But both of them looks inactive atm.

// maybe we can talk about that in jabber?

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[Vadim A. Misbakh-Soloviov]

By the way, I know that this is not a bugzilla's mirror, but it seems you did 
something wrong wile bumping. For now it refuses to build on Broadwell telling
> fftw-3.3.5/simd-support/simd-avx2.h:43:2: error: #error "compiling simd-
avx2.h without avx2 support"

Although avx2 do exist in cpuinfo (and in cpuflags_x86 too, although there is 
no such flag for fftw itself).

Re: [gentoo-dev] [RFC] lua.eclass

[Vadim A. Misbakh-Soloviov]

Thanks a lot for your review work and critics.

Just 2 cents as comments about "why the hell is going on":

> It looks like a terrible masterpiece combination of base.eclass with 
python.eclass

Actually, ruby-ng + python + some of that opera. And all of them was 
(actually, still) huge monsters with tons of magic.

I mean, the eclass (in my point of view, not really counted LOC) is 70% copied 
from ruby-ng/python eclasses, 10% "unneded" magic crap and 20% is my own work.

And main target was to... Just to write less code in the ebuilds and let 
eclass do all the magic, like ruby/perl/python/php eclsses does.


> Kill it with fire. Start over. Focus on Lua. Stop reinventing
> everything else, and attempting to convert ebuilds into some terrible
> openrc-class semi-broken declarative crap which attempts to guess what
> the developer meant.

Ok, I'll try. Although, I guess, I then fail to reach the target of having 
less code in the ebuilds as a price of being done in a right way :)

And I want to mention just once more time, that actual target was to have as 
less code in ebuilds as possible, like it is for ruby-ng, perl and python 
packages. But it seems, I turned in wrong direction somewhere.

=== semiofftopic ===

By the way, some packages authors doing monster buildsystems which is non 
intended to work with distro's package managers, and says users must use 
language-specific package manager (gem,pip,luarocks,whatever), which is fully 
supported by them.

And if previously I was supporting the point that langname-modules should be 
installed system-wide through portage, then now (after having tons of sex with 
their buildsystems just to make it to obey gentoo's practice (say, like not 
doing network operations during src_prepare/configure/compile)) I'm in doubts.

=== / ===


-- 
wbr,
mva

[gentoo-dev] [RFC] lua.eclass

[Vadim A. Misbakh-Soloviov]

Hi there!

I've done (actualy, long time ago) lua.eclass to ease maintenance of dev-lua 
packages in a way of dev-ruby and dev-python packages (including TARGETS and 
so).

All ebuilds in lua overlay is already ported to it (in basic way), although I 
recently added GITHUB_* and BITBUCKET_* magic (like rubygems and perl CPAN 
magic), and still not finished porting ebuilds to it (although, I maybe finish 
it until tonight).

So, I posting it to review and comments. And to ask your opinion about it's 
inclusion in the tree.

P.S. after few days (depends on comments in this thread) it may differ from 
up-to-date version in overlay.

-- 
wbr,
mva# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

# @ECLASS: lua.eclass
# @MAINTAINER:
# mva <l...@mva.name>
# @AUTHOR:
# Author: Vadim A. Misbakh-Soloviov <l...@mva.name>
# @BLURB: An eclass for installing Lua packages with proper support for 
multiple Lua slots.
# @DESCRIPTION:
# The Lua eclass is designed to allow an easier installation of Lua packages
# and their incorporation into the Gentoo Linux system.
#
# Currently available targets are:
#  * lua51 - Lua (PUC-Rio) 5.1
#  * lua52 - Lua (PUC-Rio) 5.2
#  * lua53 - Lua (PUC-Rio) 5.3
#  * luajit2 - LuaJIT 2.x
#
# This eclass does not define the implementation of the configure,
# compile, test, or install phases. Instead, the default phases are
# used.  Specific implementations of these phases can be provided in
# the ebuild either to be run for each Lua implementation, or for all
# Lua implementations, as follows:
#
#  * each_lua_configure
#  * all_lua_configure

# @ECLASS-VARIABLE: LUA_COMPAT
# @REQUIRED
# @DESCRIPTION:
# This variable contains a space separated list of targets (see above) a package
# is compatible to. It must be set before the `inherit' call.
: ${LUA_COMPAT:=lua51 lua52 lua53 luajit2}

# @ECLASS-VARIABLE: LUA_PATCHES
# @DEFAULT_UNSET
# @DESCRIPTION:
# A String or Array of filenames of patches to apply to all implementations.

# @ECLASS-VARIABLE: LUA_OPTIONAL
# @DESCRIPTION:
# Set the value to "yes" to make the dependency on a Lua interpreter
# optional and then lua_implementations_depend() to help populate
# DEPEND and RDEPEND.

# @ECLASS-VARIABLE: LUA_S
# @DEFAULT_UNSET
# @DESCRIPTION:
# If defined this variable determines the source directory name after
# unpacking. This defaults to the name of the package. Note that this
# variable supports a wildcard mechanism to help with github tarballs
# that contain the commit hash as part of the directory name.

# @ECLASS-VARIABLE: LUA_QA_ALLOWED_LIBS
# @DEFAULT_UNSET
# @DESCRIPTION:
# If defined this variable contains a whitelist of shared objects that
# are allowed to exist even if they don't link to liblua. This avoids
# the QA check that makes this mandatory. This is most likely not what
# you are looking for if you get the related "Missing links" QA warning,
# since the proper fix is almost always to make sure the shared object
# is linked against liblua. There are cases were this is not the case
# and the shared object is generic code to be used in some other way.
# When set this argument is passed to "grep -E" to remove reporting of
# these shared objects.

: ${GLOBAL_CFLAGS-${CFLAGS}}
: ${GLOBAL_CXXFLAGS-${CXXFLAGS}}
: ${GLOBAL_LDFLAGS-${LDFLAGS}}

: ${NOCCACHE-false}
: ${NODISTCC-false}

[[ -n "${IS_MULTILIB}" ]] && multilib="multilib-minimal"


case ${VCS} in
git)
VCS="git-r3"
;;
hg)
VCS="mercurial"
;;
svn)
VCS="subversion"
;;
esac

[[ -n "${GITHUB_A}" && -n "${BITBUCKET_A}" ]] && die "Only one of GITHUB_A or 
BITBUCKET_A should be set!"
if [[ -n "${GITHUB_A}" ]]; then
GITHUB_PN="${GITHUB_PN:-${PN}}"
EVCS_URI="https://github.com/${GITHUB_A}/${GITHUB_PN};
DL="archive"
elif [[ -n "${BITBUCKET_A}" ]]; then
BITBUCKET_PN="${BITBUCKET_PN:-${PN}}"
EVCS_URI="https://bitbucket.org/${BITBUCKET_A}/${BITBUCKET_PN};
DL="get"
fi
if [[ -z "${EGIT_REPO_URI}" && -z "${EHG_REPO_URI}" && -z "${SRC_URI}" && -n 
"${EVCS_URI}" ]]; then
if [[ "${VCS}" = git* ]]; then
EGIT_REPO_URI="${EVCS_URI}"
elif [[ "${VCS}" = "mercurial" ]]; then
EHG_REPO_URI="${EVCS_URI}"
elif [[ -z "${VCS}" && "${PV}" != ** ]]; then
SRC_URI="${EVCS_URI}/${DL}/${GITHUB_PV:-${PV}}.tar.gz -> 
${P}.tar.gz"
fi
fi

inherit eutils ${multilib} toolchain-funcs flag-o-matic ${VCS}

EXPORT_FUNCTIONS src_unpack src_prepare src_configur

Re: [gentoo-dev] [PATCH 11/17] profiles: Remove unused NGINX_MODULES_HTTP

[Vadim A. Misbakh-Soloviov]

В письме от четверг, 26 мая 2016 г. 20:43:47 +06 пользователь Michał Górny 
написал:
> limit_conn - This module makes it possible to limit the number of
> simultaneous connections for the assigned session
> limit_req - This module allows you to limit the number of requests for a 
given session.
> limit_conn - This module makes it possible to limit the number of 
simultaneous connections for the assigned session
limit_conn duplication

> -passenger - Passenger makes deployment of Ruby web applications a breeze.
AFAIR, passenger has never been in the in-tree nginx ebuild. How did it come 
in use.desc?

-- 
wbr,
mva

Re: [gentoo-dev] Last rites: www-client/luakit

[Vadim A. Misbakh-Soloviov]

В письме от четверг, 26 мая 2016 г. 21:18:27 +06 пользователь Michael Palimaka 
написал:
> # Michael Palimaka  (26 May 2016)
> # Depends on vulnerable slot of net-libs/webkit-gtk.
> # Dead upstream. Unmaintained. Masked for removal in 30 days.
> # Bug 584186.
> www-client/luakit

Not that upstream is dead. Just another guy doing the stuff now:
https://github.com/aidanholm/luakit/commits/develop
and even
https://github.com/aidanholm/luakit/commits/webkit2

-- 
wbr,
mva

Re: [gentoo-dev] please remove me off your mailing list

[Vadim A. Misbakh-Soloviov]

> thanks.  i just don;t want my inbox full of gentoo anymore.  i use gentoo

Actually, if the case was only to "not had full INBOX of gentoo", it was 
possible to just enable "sorting" and place gentoo-dev in separate IMAP-folder 
(like I did). But I guess, you've already unsubscribed, so nevermind ;)

-- 
wbr,
mva

Re: [gentoo-dev] please remove me off your mailing list

[Vadim A. Misbakh-Soloviov]

> But if you feed a man while you teach him, he's better equipped to learn. :p

As a father of 3 kids, I'd say: if you'll teach while feeding, he would say 
"yes, I understand", but will not really study anything, and would *claim* you 
to feed him again next time...

-- 
wbr,
mva

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

[Vadim A. Misbakh-Soloviov]

> Is this actually true?  For the typical use case of daily or close to
> daily updates I'd think that git would be much more efficient.
As there were noticed multiple times on the list already, this should
not ever happen, at least, until git will support resumable
fetches/clones/whatever. Otherwise you'll make a lot of people, using
bad quality internet access, to frustrate.

Re: [gentoo-dev] games.eclass policy

[Vadim A. Misbakh-Soloviov]

17.02.2016 21:32, Denis Dupeyron пишет:
> On Wed, Feb 17, 2016 at 12:39 AM, Michał Górny  wrote:
>
>> developers who did what they cared about and ignored everything and
>> everyone else.
>>
> I don't know if I'm an exception to the rule, but I've always had fruitful
> interactions with the games team. I never felt they ignored me.
And I do (both on bz and IRC).

>> games team sole claim to games in gentoo.
>>
>  Not true. I've been maintaining games for a decade and have never been on
> the team.
And so I. In gamerlay. And then hasufell comes and said something like
that: gamerlay is unneded and just stealing users from games team. And
people should contribute to sunrise=>gentoo, and not in the "3party
overlays with bad review quality".

;)

And, as for me personally, I'm pretty fine with contributing ebuilds,
that I maintain, in overlays, and do not see the point for finishing
quizzes and joining dev teams (anyway, time to time, some developers
taking my ebuilds, editing them to gentoo-tree-quality state and
commiting it to the tree, lol ;) ).

Re: [gentoo-dev] ChangeLog

[Vadim A. Misbakh-Soloviov]

Actually, git log understands if you specify path for it (especially
after --)...


03.11.2015 02:05, Daniel Campbell пишет:
> On 11/01/2015 04:22 AM, Anthony G. Basile wrote:
> > On 11/1/15 7:16 AM, Patrick Lauer wrote:
> >> Ahoi,
> >>
> >> I'm getting mildly very irritated with the lack of easily
> >> accessible ChangeLogs for our packages.
> >>
> >> Apparently updating them stopped some time in August, so now
> >> there are some outdated ChangeLogs that don't really serve any
> >> purpose, and the easiest way for users to figure out why
> >> something changed is to yell at the clumsy gitweb.g.o interface.
> >> So instead of grep we now need lots of patience.
> >>
> >> This does not look reasonable to me.
> >>
> >> Can we please either properly remove ChangeLogs and tell people
> >> to not be curious about changes, or make them useful again?
> >>
> >> Thanks,
> >>
> >> A Gentoo User.
> >>
> > I don't have strong feelings about this, but I'm happy with `git
> > log` to tell me what's going on with packages.  I would be okay
> > with the ChangeLog files just being archived and removed.
>
>
> Is there a way for us (devs and users both) to only get `git log`
> results from a specific directory or package? I'm aware we could pipe
> git log to grep, but that seems hackish, like git has a better way to
> isolate log entries.
>
>

Re: [gentoo-dev] www-client/chromium gtk3 support

[Vadim A. Misbakh-Soloviov]

> <...> 
> I'm sorry, I wrote too briefly. hasufell seems to be saying that gtk2
> should be deprecated now. I'm just agreeing with Rich that if upstream
> supports both *and* the maintainer wants to support both, there's no
> reason to force them to only support one.
> <...>
> As Rich has mentioned already, if upstream thinks they support gtk2 but
> it crashes when using gtk2, I am perfectly fine with the maintainer
> closing the bug as WONTFIX because upstream broke things.

I absolutelly double that. That is the point which I evangelizing above.

hasufell's statement about gtk2 looks like  statement that we 
should drop "that your eudev, and, better, openrc too" and force users to move 
to SysD. Which would be a crime against Gentoo Philosophy.

But, as usual, there is a sidenote: as you remember, we've dropped Qt3/KDE3 
packages over the time (I remeber how I've upgraded to KDE4 about 7 years ago 
and there was situation, similar to current gtk2-3 one. And just right now 
there is another similar situation happening around Qt4-5). There is point to 
do such thing when upstream drop that support. Only. Also, there is a point to 
drop gtk2-only packages later, when upstreams will die. Until that, such 
proposiions looks like tyranny.

-- 
Best regards,
mva


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

Re: [gentoo-dev] www-client/chromium gtk3 support

[Vadim A. Misbakh-Soloviov]

> And its absolutely OK for a maintainer to close the bug as WONTFIX after a
> lively discussion.

Absolutelly yes. And it is users right to go and make that theyself (either in 
overlay or by proxymaint).

The key of mystatement was in that NOBODY in Gentoo can (at least, should not 
have the power to be able to) dictate which features mainainers (which is most 
of the time are users of maintained packages) should maintain, and which they 
shall exclude. Maximum censorship is about ebuilds coding quality. But nobody 
ever should try to dictate "we should drop baselayout, because of systemd", 
"we should drop one toolkit becouse of another", and so on.

-- 
Best regards,
mva


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

Re: [gentoo-dev] Re: www-client/chromium gtk3 support

[Vadim A. Misbakh-Soloviov]

В письме от Чт, 10 сентября 2015 17:43:30 пользователь Duncan написал:
> So I've learned (the hard way) to use *stars* or _underlines_ (or for 
> lower levels, /italics/) for emphasis, and only use ALL CAPS when I 
> really do intend to SHOUT, which isn't often.

Ok. Thank you for netiquette reminder.

I apologize to everyone who might be hurt by that my statement.

And, actually, imagine that speech in IRL, I'd really say that sentence part 
("we've no right to dictate") a bit louder than the rest. Alhough, yes, I 
didn't mean the loud shoud.


-- 
Best regards,
mva


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

Re: [gentoo-dev] ALLARCHES and the maintainer action(s)

[Vadim A. Misbakh-Soloviov]

> So, if an arch developer tests the package(s) on one architecture, he is
> allowed to stabilize/keyword for all.

And how about the
> some arches rquires additional tests during stabilization, like so: mips*, 
arm*, and some more exotic ones
definition in developer manuals? :)

-- 
Best regards,
mva


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

Re: [gentoo-dev] www-client/chromium gtk3 support

[Vadim A. Misbakh-Soloviov]

I disagree witho you and hasufell.

It *IS* users destiny if they get some stabiity issues because of their 
decision to have gtk2-only or gtk3-only system.

Yes, they can paste bugs about improper toolkit support. Is it bad? Rules says 
it should be reported upstream. And all the time Gentoo exists that worked 
this way.

The whole point of Gentoo is to give user freedom of the choice. Freedom to 
decide every aspect that is possible to decide about. Freedom to use Gentoo 
exactly as they want, but not as "you don't need feature X, because I'm 
maintainer/QA and said that", like some DebUbuntu maintainers did with git or, 
say, ejabberd, some years ago. Any movements to the easy side of "we will not 
support feature X, despite upstream still support it, because feature Y is 
newer and shiny, and feature X can be less tested" is a big fat violation of 
Gentoo philosophy.

And I totally agree with Rich: it is maintainer decision, if they ready to 
support mutiple build variants or not. And if not — it is absolutelly lawful 
user's right to file a bug against a package, that it has support in upstream, 
but has not in the Gentoo.

WE HAVE NO RIGHT TO DICTATE users what they should use and what they should 
not. We are makers of kinda army swiss knife suite that give user possibility 
and instruments to make everything they want. And any tries to say "you shall 
use SystemD, but not sysV/openrc/upstart/whatever", or "you shall use gtk3 
only", or "you shall use Qt5 only", and so on — is a CRIME against Gentoo 
philosophy.

-- 
Best regards,
mva


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

Re: [gentoo-dev] cmake-utils.eclass: two improvements

[Vadim A. Misbakh-Soloviov]

It is bad way to just disable RPATH in eclass without any buttons to enable 
it back. Moreover, it is bad to disable it even with such buttons. THe right 
way would be to detect if portage instance calling eclass is in PREFIX and 
depends on that — keep it or disable.

-- 
Best regards,
mva


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

Re: [gentoo-dev] Re: RFC: Indention in metadata.xml

[Vadim A. Misbakh-Soloviov]

 * linewidth  80 (why do we have this short limit still in 2015)

Actually, I dislike that too, but the reason is simple: some people still 
using text-mode terminals.

// It would be nice to finally fix that, but let's be realistic: it looks like 
it wouldn't be finished in the near 10 years :-/

-- 
Best regards,
mva


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

Re: [gentoo-dev] oops: portage-latest.tar.* are off-by-one.

[Vadim A. Misbakh-Soloviov]

В письме от Чт, 4 июня 2015 11:17:01 пользователь Mike Frysinger написал:
 if you have a bug to report, please use bugs.gentoo.org
 -mike

I bet, bug will deprecate itself before even bug wranglers takes a look on 
it.

-- 
Best regards,
mva


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

Re: [gentoo-dev] A question to Russian Gentoo Developers Community about import software substitution

[Vadim A. Misbakh-Soloviov]

 
 I had been trying to push the idea of creating an united FOSS community
 to solve problems of the higher school of the Russian Federation. But
 such initiatives faded due to absence of support of top executives… And
 now (according to e.g. [1]) it won't be a problem, IMHO.

It would. Just because of the fact, that top executives (in Education Dept, 
in regional ministerys and so on) is that kind of clerks, that WOULDN'T accept 
anything if it is impossible to get (read as steal) some money in personal.

 And I'd prefer
 make a distribution for the higher shool based on Gentoo Linux.

I'd also prefer, but it is not that possible as you imagine. There is such 
thing as certification in Federal Security Service (FSB) and so on. And there 
is only two such distributions: Alt Linux and Rosa Linux (if not talking about 
GPL-violating MSVS and Elbrus OS with unknown status of GPL violation (since 
I'm not ready to pay $5k just to check if sources will be included there)).

 So
 here's the Question:
 
 Does anybody interested in creating a consortium to send an application
 to the Ministry of Communications?

I'm partially interested to mentally maintain that, but I have to free time to 
activelly do anything in personal (but, probably, will be fine in a group).
And, except of that, I even very interested in in-place integration, 
because: 1) I'm Gentoo-affiliated IT company CEO (and intereted in Gentoo 
popularity, and have legal possibility for in-place integration in the city I 
live now), 2) I'm a thrice father and dislike the idea my children will be 
forced to learn some M$-produced bloatware. That's why I very like the idea of 
FLOSS/Linuxes at all (and Gentoo in particular) in the schools.
But, as I said, I doubt in success of that operation. But... Let the Force be 
with us...


P.S. I'd not use politic-related phrases (like import software substitution) 
in international communities at all and here in particular.

-- 
Best regards,
mva


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

Re: [gentoo-dev] Re: git://anongit.gentoo.org is extremely slow

[Vadim A. Misbakh-Soloviov]

 It was not a location problem, because only git:// seemed to be affected:
 
git clone git://...- 15KB/s
git clone https://...  - 2MB/s

Looks like shaping on ISP side (i.e. it doesn't hear about Network 
Neutrality).

// Although, of course, it can be result server overloading and only infra-
team can investigate and tell real reason ;)

-- 
Best regards,
mva


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

Re: [gentoo-dev] CGA Web™ graphics standards

[Vadim A. Misbakh-Soloviov]

 I thought PetBox was pretty funny too.
 
 http://www.redbox.com/petbox?icamp=hp:mss:aprilfoolspetbox:4:1:2015

403 :(

-- 
Best regards,
mva


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

Re: [gentoo-dev] CGA Web™ graphics standards

[Vadim A. Misbakh-Soloviov]

 
 Nearly as funny as the one about Gentoo switching to CVS.

From what? AFAIR, it still on CVS...

-- 
Best regards,
mva


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

Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

Yes, we should add possibilities, but not revoke them from user.
That is a Gentoo Philosophy.
We shouldn't enforce users to anything that, as we think, is better for them.
Even about security.

And yes, we even shouldn't forbid them to install heartbleaded openssl 
(thankfully, users is free to do that themselves from local overlays).

-- 
Best regards,
mva


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

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

Despite of all you're talking about is right from paranoid point of view, I'd, 
anyway, say DO NOT DO THAT, because you propose to revoke the right of 
choice from the users.

It is user's decision, which protocol to use to fetch the sources. Although, 
you're, of course, free to make layman to fetch official repos from https, 
but not http/git protocols by default.

Moreover, there are some times where it is impossible to fetch sources via 
secure way, but you need it right here and right now.





В письме от Вс, 29 марта 2015 18:41:33 пользователь Sebastian Pipping написал:
 Hi!
 
 
 For the current Gentoo Git setup I found these methods working for
 accessing a repository, betagarden in this case:
 
   git://anongit.gentoo.org/proj/betagarden.git
  (git://git.gentoo.org/proj/betagarden.git)
  (git://git.overlays.gentoo.org/proj/betagarden.git)
 
   http://anongit.gentoo.org/git/proj/betagarden.git
 
  (http://cgit.gentooexperimental.org/proj/betagarden.git)
 
   git+ssh://g...@git.gentoo.org/proj/betagarden.git
  (git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git)
 
 Those without braces are the ones announced at the repository's page [1].
 
 My concerns about the current set of supported ways of transfer are:
 
  * There does not seem to be support for https://.  Please add it.
 
  * Why do we serve Git over git:// and http:// if those are vulnerable
to man-in-the-middle attacks (before having waterproof GPG
protection for whole repositories in place)?
Especially with ebuilds run by root, we cannot afford MITM.
 
 
 So I would like to propose that
 
  * support for Git access through https:// is activated,
 
  * Git access through http:// and git:// is deactivated, and
 
  * the URLs on gitweb.gentoo.org and the Layman registry are
updated accordingly.  (Happy to help with the latter.)
 
 
 Thanks for your consideration.
 
 Best,
 
 
 
 Sebastian
 
 
 [1] https://gitweb.gentoo.org/proj/betagarden.git/

-- 
Best regards,
mva


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

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

 Doesn't git:// uses SSH wich is secure? I think that was on github.
git+ssh:// — does. git:// — does not. It is just git-daemon listening on 
separate port and serving plaintext, readonly (by default) access.

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

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

 GitHub does not support git:// but only secure protocols (HTTPS, SSH),
GitHub DO (!) support git://

$ git clone git://github.com/msva/mva-overlay.git
Cloning into 'mva-overlay'...
remote: Counting objects: 10435, done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 10435 (delta 11), reused 0 (delta 0), pack-reused 10393
Receiving objects: 100% (10435/10435), 2.99 MiB | 758.00 KiB/s, done.
Resolving deltas: 100% (5132/5132), done.
Checking connectivity... done.


 see [2].

shoud-i-use != do not support

-- 
Best regards,
mva


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

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

 
 They would not do online banking over http, right?  Why would they run
 code with root privileges from http?

1) Actually, they will :(
2) Because they can't review what bank received via insecure channel, while 
they can review what they're themselves received via http/git.

-- 
Best regards,
mva


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

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

 pedantOpenPGP (GPG is just one implementation)/pedant, but indeed,
 that is what the gentoo-keys project is about. There is experimental
 support for OpenPGP verification in portage already using gkeys.
 Currently the focus is on getting developer's keys up to GLEP63 specs,
 i currently see 36 good Gentoo developer keys. The scheme is also
 flexible enough to allow for overlays.
 
 
 https is not a good protection against MITM when factoring in global
 PKIX CA setup, nor would it protect with regards to server compromise.
 So the only viable way to secure ebuild repositories is proper OpenPGP
 usage.

I'd double that pedant paranoid! :)

-- 
Best regards,
mva


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

[gentoo-dev] Thoughts about LUA_TARGETS

[Vadim A. Misbakh-Soloviov]

Hi!
As you can be noticed, Lua packages, just like Python, PHP or Ruby ones, 
supports slotted behaviour (with some side notes).
As far as we have nice *_TARGETS for languages above (without standardised 
naming syntax, although), we still do not have such for Lua.

Rafael's main argument is about that fact, that Lua releases between 
themselves has incompatible bytecode, sometimes syntax (just as all 
interpreters above), and that LuaJIT has incompatible bytecode even with 
version it is built to be as (i.e. libluajit-5.1 bytecode is incompatible with 
liblua-5.1, and so on for 5.2 and 5.3).

But as far as I know, it is same issues between CPython and PyPy, and between 
MRI and Rubinius.

So, I'd like to escalate that problem, finally make some decision and finally 
introduce LUA_TARGETS on packages ;).


-- 
Best regards,
mva


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

Re: [gentoo-dev] [RFC] luajit global useflag

[Vadim A. Misbakh-Soloviov]

В письме от Вс, 1 марта 2015 20:36:03 пользователь Ben de Groot написал:
 
 Or maybe one of the other lua package maintainers has plans?


Not that I'm in-tree lua maintainer, but as Lua-overlay contributor and lua-
fanboy, I'd suggest to unmask all lua-interpreters and make them slotted just 
as python/ruby/whatever. And provide a eselect-lua (I had ebuild for it 
somewhere).

Although, there is single issue: precompiled bytecode isn't compatible between 
even 5.1 PUC-Rio Lua and LuaJIT, and, of course, AFAIR, between Lua5 
releases.

But I don't think Lua-users do not know about that, so I don't think it is a 
real problem.

-- 
Best regards,
mva


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

Re: [gentoo-dev] [RFC] luajit global useflag

[Vadim A. Misbakh-Soloviov]

В письме от Чт, 26 февраля 2015 13:36:24 пользователь Ben de Groot написал:

 I propose we make luajit a global useflag, using the description from
 media-sound/csound:
 
 Use the lua just-in-time compiler pkgdev-lang/luajit/pkg instead
 of pkgdev-lang/lua/pkg

Voting up!

Although, I'd also propose lua.eclass and patch all ebuilds declaring Lua 
support to support building against LuaJIT as well (since they're fully 
compatible at runtime).

-- 
Best regards,
mva


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

Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps

[Vadim A. Misbakh-Soloviov]

 
 Thanks. But I think we can simplify that for now, since lua53 isn't
 available (neither in the official tree or the lua overlay) and
 
 =lua-5.2 is hardmasked.

Anyway, I think, we need my default patch for luajit support here (which, 
actually, I'd suggest to apply on all packages in the tree, that declares Lua 
support. Should I start thread about it here?):

iuse+=luajit
deps~= luajit? (dev-lang/luajit:2) !luajit? ( dev-lang/lua )
or

src_configure/install {
local lua=lua
use luajit  lua=luajit

INST_PATH_LMOD=$($(tc-getPKG_CONFIG) --variable INSTALL_LMOD ${lua})
# and/or INST_PATH_CMOD=$($(tc-getPKG_CONFIG) --variable INSTALL_CMOD ${lua})
}

instead of default hard-dep on puc-rio lua... ;)

-- 
Best regards,
mva


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

Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps

[Vadim A. Misbakh-Soloviov]

I'd also say:

neovim:

 CDEPEND=dev-lang/luajit
 ...
   dev-lua/LuaBitOp

1) I'm not sure luajit:1 fits the dep
2) LuaJIT:2 has it's own bit modules and is unneded LuaBitOp

Unibilium:
1.1.2 made a day ago. Bump, please ;)

lua-MessagePack:
 RDEPEND==dev-lang/lua-5.1
And what about LuaJIT? Huh?
Also, I've it in lua overlay, called dev-lua/messagepack, though. Naming can 
be discussed. But main point is:

 RDEPEND=
!luajit? (
!lua53? (
|| (
=dev-lang/lua-5.1*
=dev-lang/lua-5.2*
)
)
lua53? ( =dev-lang/lua-5.3* )
)
luajit?  ( dev-lang/luajit:2 )

 ...
src_install() {
local lua=lua
use luajit  lua=luajit

insinto $($(tc-getPKG_CONFIG) --variable INSTALL_LMOD ${lua})
if use lua53; then
doins src5.3/MessagePack.lua
else
doins src/MessagePack.lua
fi
}

(I wrote src_install that time when Makefile either was missing or buggy, 
anyway, take a notice on conditions)




-- 
Best regards,
mva


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

Re: [gentoo-dev] ROS (Robot Operating System) Overlay for Gentoo

[Vadim A. Misbakh-Soloviov]

В письме от Вт, 18 ноября 2014 14:38:12 пользователь Wayne Chang написал:
 Hi All,
hi
 
 What's the best way to get this
 repository recognized as an official overlay?

Create a bug on bz to include in in the oficial layman list.
Like this: https://bugs.gentoo.org/show_bug.cgi?id=444666 or this: 
https://bugs.gentoo.org/show_bug.cgi?id=405615

-- 
Best regards,
mva


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

Re: [gentoo-dev] Re: Implicit system dependency

[Vadim A. Misbakh-Soloviov]

В письме от Вт, 18 ноября 2014 03:28:08 пользователь Duncan написал:
 Tho I actually appreciate the you get to keep the pieces aspect as
 Unlike many distros, gentoo actually respects the user and their
 right to decide enough to give them the /power/ to break the system, if
 they drink and emerge, or similar foolish things.  The guard rails are
 there and that's appreciated, but there's also unlocked gates (with clear
 warnings on them) thru those guard rails, because that's what gentoo is
 /about/.  Sure, people can and do go thru those gates from time to time,
 but it's their responsibility to be appropriately roped up if they do,
 and if they can't do that and end up falling off the gentoo cliff and
 landing on arch or fedora (or even osx or ms windows!) instead, well, it
 was probably for the best.
 
 So let's keep the warnings there as they do warn the unwary, but also the
 unlocked gates thru those default-use railings.  =:^)

That message should be sent as auto-reply to every 1.5 messages in this thread 
(and maybe in entire gentoo-dev, I think)! :)

-- 
Best regards,
mva


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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-nds/openldap/files: openldap-2.4.40-db-6.patch

[Vadim A. Misbakh-Soloviov]

Btw, since Gentoo do not (mostly) provide packages itself, but only
build instructions (ebuild), can't we just ship ebuild that patches
openldap violates to force to use db6 with bindist USE?

I.e. make user decide to take responsibility for that local license
incompatibility. We're all know, that it is pretty acceptable to locally
do the things, that OSS licenses incompatibility forbids (if you do not
have plans to redistribute that binary). So why just don't ease user's
life? :)



--
Best regards,
mva



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

Re: [gentoo-dev] cvs.gentoo.org, git.gentoo.org, *.overlays.gentoo.org migration timeline ssh keys

[Vadim A. Misbakh-Soloviov]

Btw, I've noticed git.overlays.gentoo.org moved to Hetzner.

When I remember my expirience of work with Hetzner - I'm scary about Gentoo' 
infrastructure destiny.


I had a conversation with CEO of my current DDoS-proof hoster and he expressed 
his desire to help interesting projects and asked about the necessary amount 
of sponsorship and it's terms (and conditions).

So, can I ask you to provide some info about infra team hardware requirements 
(which amount needs to be sponsored) and if it is any sponsoring conditions 
that Gentoo Foundation can suggest to the sponsor (maybe some banner, or 
something like that)?

Anyway, mainly I need the amount of hardware gentoo infra team requires to 
[strike]get rid of hetzner[/strike] meet their comfortable-work 
requirements? Then I can discuss it with hoster again and then bring together 
somebody from infra-team and hoster's CEO or CTO to discuss the terms 
themselves.



-- 
Best regsrds,
mva


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

Re: [gentoo-dev] Re: The request to abolish games team policy

[Vadim A. Misbakh-Soloviov]

В письме от Пт, 11 июля 2014 16:24:38 пользователь hasufell написал:

 However, basically having only a single person that actively does such
 reviews + no official overlay makes it hard for contributors.

As I said previously, you (and any developer else) are free to get a reviewer 
role
for gamerlay (and make it official overlay).
But, AFAIR, you're opinion is hat gamerlay must die...

So, we fall into infinite circle (exaggeratedly):
— There is no official overlay and no reviewers!
— You can use gamerlay as a base for that and we can change our workline for 
you.
— Gamerlay is unneded!
...
— We need reviewers and official overlay.


--
Best regsrds,
mva



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

Re: [gentoo-dev] Re: The request to abolish games team policy

[Vadim A. Misbakh-Soloviov]

В письме от Вт, 8 июля 2014 18:22:50 пользователь Samuli Suominen написал:
 It seems to me like people aren't making the effort of joining to the
 team and meeting the high quality
 ebuild syntax they've kept up...

Samuli! With all my respect to you personally, please, don't tell anything 
about high quality of ebuilds syntax by the games team. Please.

-- 
Best regsrds,
mva


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

[gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)

[Vadim A. Misbakh-Soloviov]

My idea is to allow failing for some patches without breaking build at all. 
And, in parallel, to
add groupping.

How I imagine that:

etc/portage/patches/app-cat/name/
|
| - group_name/
| |
| |- 01_foo.patch
| |- 02_bar.patch
| |- ...
|
|- 01_moo.patch
|- 99_meow.patch

Where every first-level piece (patch or group) in 
```etc/portage/patches/app-cat/name/``` MAY
tolerably fail (not causing die for emerge), but if one of the patches inside 
the group fails, then
group MUST NOT be applied at all (and all previously applied patches from this 
group MUST be
reversed).


Any objections/approvals/suggestions?




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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-strategy/openxcom: openxcom-1.0.0.ebuild metadata.xml Manifest ChangeLog

[Vadim A. Misbakh-Soloviov]

В письме от Сб, 14 июня 2014 20:06:54 пользователь hasufell написал:
 Maxim Koltsov (maksbotan):
  ...

What about adding such checks in repoman?

P.S.

 Did you get a review from the games team?

You're right in all remarks, but Maxim is just proxy here.
And I'm not sure if original maintainer reads -dev. So, you'd probably address 
remarks him.

// Although, we're already forwarded this email to him.

-- 
Best regsrds,
mva



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

Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?

[Vadim A. Misbakh-Soloviov]

   rc-update del vixie-cron default
   /etc/init.d/vixie-cron stop
   emerge -C vixie-cron
   emerge cronie
   rc-update add cronie default
   /etc/init.d/cronie start

Why /etc/init.d instead of rc-service? :)

-- 
Best regsrds,
mva

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

Re: [gentoo-dev] last rites: dev-db/edb

[Vadim A. Misbakh-Soloviov]

19.09.2013 11:44, Michael Sterrett пишет:
 # Michael Sterrett mr_bon...@gentoo.org (19 Sep 2013)
 # dead upstream and unused by anything in the tree
 # masked for removal on 20131019
 dev-db/edb
 

Are you sure, that enlightenment is dead?
Not that I'm opposite to delete the dep of old prehistoric version of
enlightenment, but I just can't get, why do you think that upstream is
dead...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?

[Vadim A. Misbakh-Soloviov]

 2. Kill EGIT_HAS_SUBMODULES and autodetect submodules,

I'm disagreed. Sometimes submodules, that repo suggests is unneded,
since they fetches external package, that specified as RDEP.

 
 3. Kill EGIT_OPTIONS since it limits the possibility of changing eclass
code,

:-/

 4. Kill EGIT_MASTER (it's more trouble than benefit),

Only if EGIT_BRANCH will stay on it's place.

 5. Possibly kill EGIT_PROJECT -- it won't be good enough anymore,

Why?

 6. Kill EGIT_NONBARE and support bare checkouts only. Supporting two
different layouts introduces a lot redundant code.

AFAIR, that was issues (including shallow clones and so on), that
refuses to use bare repo.



signature.asc
Description: OpenPGP digital signature