Re: [gentoo-dev] Looking for co-maintainers for number of packages

2022-07-07 Thread Alexey Sokolov

07.07.2022 11:27, Martin Kletzander пишет:

On Sun, Jul 03, 2022 at 09:03:04PM -0700, Georgy Yakovlev wrote:

I've been rather busy lately and can't keep up with all of my packages.
There are pending bumps, some bugs, but nothing too crazy or hard.
So I'm looking for someone to co-maintain (or even take over if you
insist) the following packages:



Noob question, I would have to be a Gentoo developer/maintainer to help
with that, am I right?


Don't worry, proxied maintainers can easily (co-)maintain packages too.


* app-shells/fish
Responsive upstream, not very frequent releases, cmake. Requires some
attention on non-x86 as arch bugs are rather frequent. But nothing too
crazy.



Since I do not have any experience with official maintainership I would
hesitate to commit to anything I am not a user of, but I do use fish and
keep an eye on releases a bit (which I would do more, of course).

[...]


PS. Huge bonus if you can test packages not only on x86_64.
Ofc I can help with some gotchas in packages and have no plans on
abandoning those completely, but realistically I'm not doing enough to
keep those properly maintained at the moment.



I can test that every now and then and even fix some possible issues,
hopefully.

Let me know if I can be of help or whether I should rather go through
proxy maintainers or another route.


It's possible for a particular developer to be the proxy, and it's 
possible for p-m project to be proxies for the proxied maintainers.




Have a nice day,
Martin




--
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: Prefer "rm -rf build" over "setup.py clean -a"

2022-04-17 Thread Alexey Sokolov

09.04.2022 17:37, Michał Górny пишет:

Prefer using "rm -rf build" directly over "setup.py clean -a".  This
has three advantages:

1. It is much faster.

2. It works on packages that have broken "setup.py clean",
e.g. dev-python/pydantic.

3. It works on packages that block "setup.py clean" and tell you to use
"git clean" (sic!), e.g. dev-python/scipy.

This is a potentially (but unlikely) breaking change, so do it
conditionally to GPEP517_TESTING.

Signed-off-by: Michał Górny 
---
  eclass/distutils-r1.eclass | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index de891215e688..e6b0ab5e0e32 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1090,7 +1090,11 @@ distutils_pep517_install() {
# clean the build tree; otherwise we may end up with PyPy3
# extensions duplicated into CPython dists
if [[ ${DISTUTILS_USE_PEP517:-setuptools} == setuptools ]]; then
-   esetup.py clean -a
+   if [[ ${GPEP517_TESTING} ]]; then
+   rm -rf build || die
+   else
+   esetup.py clean -a
+   fi
fi
  }
  


rm -r build || die

-f makes it not fail, which makes ||die useless

--
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] [RFC] [News Item] Qt 5.15.3 version bump with binary path changes

2022-03-27 Thread Alexey Sokolov

27.03.2022 08:57, Andreas Sturmlechner пишет:

Title: Qt 5.15.3 version bump with binary path changes
Author: Andreas Sturmlechner 
Posted: 2022-03-27
Revision: 1
News-Item-Format: 2.0


Add Display-If-Installed: qt?



Up until Qt 5.15.2 we were using qtchooser to provide unversioned links to Qt
binaries in PATH, like qmake, moc, qmljs etc. Starting with 5.15.3 such links
will be installed by each respective Qt package and '5'-version-suffixed, e.g.
qmake becomes qmake5, qml becomes qml5 etc., mirroring Qt6.

If you develop with Qt5 and rely on unversioned binaries for your workflow,
dev-qt/qtchooser as a tool for quickly switching between multiple Qt
installations (e.g. Qt3, Qt4 and Qt5) can still be manually installed. The
'default' Qt version in PATH is then controlled via config in
/etc/xdg/qtchooser.

Otherwise, dev-qt/qtchooser will be slated for cleanup on your next emerge --
depclean run.


Russian translation follows

Title: Новая версия Qt 5.15.3 меняет имена исполняемых файлов
Author: Andreas Sturmlechner 
Translator: Alexey Sokolov 
Posted: 2022-03-27
Revision: 1
News-Item-Format: 2.0

В версиях Qt по 5.15.2 мы использовали qtchooser, чтобы устанавливать 
исполняемые файлы Qt в PATH без номера версии, такие как qmake, moc, 
qmljs и т.д. Начиная с версии 5.15.3 эти файлы будут установлены самим 
соответствующим пакетом Qt и будут заканчиваться на "5": например, qmake 
станет qmake5, qml станет qml5 и т.д., так же, как это делает Qt 6.


Если вы используете Qt5 при разработке, и ваш рабочий процесс зависит от 
этих файлов без версии, вы всё ещё можете установить dev-qt/qtchooser — 
инструмент для быстрого переключения между различными установленными Qt 
(например, Qt3, Qt4, Qt5). В таком случае версия Qt в PATH по умолчанию 
настраивается в /etc/xdg/qtchooser.


В противном случае dev-qt/qtchooser будет удалён при следующем запуске 
emerge --depclean.


--
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] Feature request: auto-CC for bugs modified via commit tags

2022-01-25 Thread Alexey Sokolov

25.01.2022 17:33, Sam James пишет:




On 25 Jan 2022, at 17:00, Michael Orlitzky  wrote:

Can I request that Bug: and Closes: tags in our commits automatically
CC the committer on the bug that is modified?

Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user
will leave a comment like "it still crashes on x86" that I never see.
Of course, I could manually CC myself on every bug. But that will send
everyone an extra email, and is forgettable. Plus, avoiding the manual
step is kind of the point of the automation, right?

One potential downside is that the commit author could wind up CCed
twice via an alias, but that could be solved with a sufficiently clever
implementation. Or disregarded if it's not too much of a problem in
practice; the bugs will usually be closed, after all.



I'd quite like this as I do a fair amount of drive-bys.


Yes please. There were a few cases where I broke something when trying 
to fix something and didn't notice the report.




Thanks for bringing it up.

Best,
sam



--
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

2022-01-05 Thread Alexey Sokolov
I do sometimes run into OOM during emerge, but for a different reason: 
when firefox and webengine are built in parallel. And I'm using tmpfs 
for portage. These packages store lots of data in the build directory. 
Decreasing -j of a single package may or may not help in this case.


The filled tmpfs issue becomes more severe if I have tests enabled, 
because ctest has different behavior from make/ninja, and I use -j with 
combination with -l: make and ninja run at least one job to ensure some 
progress, while ctest does nothing when the load average is too high, 
and while it's doing nothing, the portage cannot finish the build and 
therefore cleanup the build dir from RAM.


Neither of these are exactly relevant to this patch, tbh.

04.01.2022 22:58, Sam James пишет:

Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the
amount of RAM available (uses amount declared as needed
in the ebuild). Typically should be ~2GB per job.

Bug: https://bugs.gentoo.org/570534
Signed-off-by: Sam James 
---
  eclass/check-reqs.eclass | 42 +---
  1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
index 2130e2e349141..8c4adc8b4f121 100644
--- a/eclass/check-reqs.eclass
+++ b/eclass/check-reqs.eclass
@@ -43,6 +43,8 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI=${EAPI:-0} is not supported" ;;
  esac
  
+inherit multiprocessing

+
  EXPORT_FUNCTIONS pkg_pretend pkg_setup
  
  if [[ ! ${_CHECK_REQS_ECLASS} ]]; then

@@ -53,6 +55,13 @@ _CHECK_REQS_ECLASS=1
  # @DESCRIPTION:
  # How much RAM is needed? Eg.: CHECKREQS_MEMORY=15M
  
+# @ECLASS-VARIABLE: CHECKREQS_MEMORY_MANGLE_JOBS

+# @USER_VARIABLE
+# @DESCRIPTION:
+# Allow packages to reduce the number of multiprocessing (e.g. make, ninja) 
jobs
+# to lower memory usage.
+: ${CHECKREQS_MEMORY_MANGLE_JOBS=yes}
+
  # @ECLASS-VARIABLE: CHECKREQS_DISK_BUILD
  # @DEFAULT_UNSET
  # @DESCRIPTION:
@@ -346,9 +355,36 @@ _check-reqs_memory() {
eend 0
else
eend 1
-   _check-reqs_unsatisfied \
-   ${size} \
-   "RAM"
+
+   # Has the user allowed us to mangle their MAKEOPTS?
+   if [[ ${CHECKREQS_MEMORY_MANGLE_JOBS} == "yes" ]] ; then
+   local jobs=$(makeopts_jobs)
+
+   local 
estimated_max_memory=$((${actual_memory}/$(_check-reqs_get_kibibytes 1G)))
+   if [[ $((jobs*2)) -gt ${estimated_max_memory} 
]] ; then
+   # Number of jobs exceeds RAM/2GB, so 
clamp it.
+   local 
new_jobs=$(($(_check-reqs_get_number ${estimated_max_memory}G)*10/20))
+
+   # This might _still_ be too big on 
small machines. Give up in such cases.
+   # (Users can still set the do nothing 
variable which is independent of this.)
+   if [[ $((new_jobs*2)) -gt 
${estimated_max_memory} ]] ; then
+   _check-reqs_unsatisfied \
+   ${size} \
+   "RAM"
+   else
+   # The clamped jobs seem to be 
enough to satisfy the check-reqs requirement from the ebuild.
+   ewarn "Clamping MAKEOPTS jobs to 
-j${new_jobs} to reduce memory usage"
+   ewarn "Compiler jobs may use around 
~2GB each: https://wiki.gentoo.org/wiki/MAKEOPTS;
+   ewarn "To disable this, set 
CHECKREQS_MEMORY_MANGLE_JOBS=no."
+
+   MAKEOPTS+=" -j${new_jobs}"
+   fi
+   fi
+   else
+   _check-reqs_unsatisfied \
+   ${size} \
+   "RAM"
+   fi
fi
else
eend 1



--
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] Last rites: media-sound/clementine

2021-12-18 Thread Alexey Sokolov

07.12.2021 06:29, Zoltan Puskas пишет:

On Tue, Dec 07, 2021 at 07:11:23AM +0100, Lars Wendler wrote:

On Mon, 6 Dec 2021 23:56:10 + Alexey Sokolov wrote:


24.11.2021 11:33, Lars Wendler пишет:

No real development since Q1 2020. Last release from 2016.
Users should switch over to media-sound/strawberry which is an
actively developed fork.
Masked for removal in 30 days.




I've tried strawberry, but it's unusable [1]. At least until bugs are
fixed, can it be unmasked? I can take maintainership if needed.

[1] https://github.com/strawberrymusicplayer/strawberry/issues/849



Saying that it's "unusable" is quite a misleading claim when in fact
only keyboard shortcuts do not work...

--
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


Not to fan the flames (ok, maybe a little bit), but web radio support is
also rather limited in Strawberry if we are being completely honest
(i.e. awful user experience). I'm saying this as a person who has
transitioned away from clementine quite some time ago.

Cheers,
Zoltan



Lars, can you merge https://github.com/gentoo/gentoo/pull/23209 ?

--
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] Last rites: media-sound/clementine

2021-12-07 Thread Alexey Sokolov

07.12.2021 06:11, Lars Wendler пишет:

On Mon, 6 Dec 2021 23:56:10 + Alexey Sokolov wrote:


24.11.2021 11:33, Lars Wendler пишет:

No real development since Q1 2020. Last release from 2016.
Users should switch over to media-sound/strawberry which is an
actively developed fork.
Masked for removal in 30 days.




I've tried strawberry, but it's unusable [1]. At least until bugs are
fixed, can it be unmasked? I can take maintainership if needed.

[1] https://github.com/strawberrymusicplayer/strawberry/issues/849



Saying that it's "unusable" is quite a misleading claim when in fact
only keyboard shortcuts do not work...



I'm sorry, but how am I supposed to use a media player which doesn't let 
me start/stop the playback?


This is a clear regression from clementine which has this basic 
functionality.


--
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] Last rites: media-sound/clementine

2021-12-06 Thread Alexey Sokolov

24.11.2021 11:33, Lars Wendler пишет:

No real development since Q1 2020. Last release from 2016.
Users should switch over to media-sound/strawberry which is an actively
developed fork.
Masked for removal in 30 days.




I've tried strawberry, but it's unusable [1]. At least until bugs are 
fixed, can it be unmasked? I can take maintainership if needed.


[1] https://github.com/strawberrymusicplayer/strawberry/issues/849

--
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test

2021-10-20 Thread Alexey Sokolov
20.10.2021 09:40, James Beddek пишет:
> As part of transitioning to using Clang as my system compiler, I have been 
> running tests on most
> packages to determine if they still properly function. However, this has 
> introduced a problem where
> some KDE package tests segfault.
> Unfortunately, this launches DrKonqi in the virtx display to display a 
> backtrace.
> 
> This results in the test phase hanging as DrKonqi is presumably waiting for 
> user input.
> See below for an instance of a test phase hanging as seen through `top -b -c 
> -n 1 -u portage`:
> 
> PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
> 3441869 portage   30  102360   1560   1400 S   0.0   0.0   0:00.00 
> [kde-apps/ark-21.08.2] sandbox /usr/lib/portage/python3.9/ebuild.sh test
> 3441870 portage   30  10   12896   7688   3592 S   0.0   0.0   0:00.01 
> /bin/bash /usr/lib/portage/python3.9/ebuild.sh test
> 3441886 portage   30  10   13036   6296   2064 S   0.0   0.0   0:00.01 
> /bin/bash /usr/lib/portage/python3.9/ebuild.sh test
> 3441908 portage   30  10  150436  59128  44836 S   0.0   0.1   0:00.03 
> /usr/bin/Xvfb :16 -screen 0 1280x1024x24 +extension RANDR
> 3441936 portage   30  10   55000  15512  13416 S   0.0   0.0   0:00.02 ctest 
> -j 16 --test-load 999
> 3441938 portage   30  10  487364  58044  46480 T   0.0   0.1   0:00.20 
> /var/tmp/portage/kde-apps/ark-21.08.2/work/ark-21.08.2_build/bin/addtoarchivetest
> 3442262 portage   30  109176   2336   1600 S   0.0   0.0   0:00.00 
> dbus-launch --autolaunch 8d4328e526b647a5a2e029d1e0814ba6 --binary-syntax 
> --close-stderr
> 3442279 portage   30  109460   4180   3408 S   0.0   0.0   0:00.00 
> /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 
> --session
> 3444712 portage   30  10  350068  94032  78820 S   0.0   0.1   0:00.15 
> /usr/lib64/libexec/drkonqi --platform xcb --display :16 --appname 
> addtoarchivetest
> ___
> 
> As far as I can tell, without sending SIGKILL to the test being traced 
> (addtoarchivetest in this instance), the test phase never exits.
> 
> KDE provides a variable, KDE_DEBUG [1], which when set disables the DrKonqi 
> crash handler.
> Using this results in the tests segfaulting and the test phase simply 
> failing, rather than hanging.

Do crashes of other (non-ecm) tests trigger DrKonqi too? What's the
reason to add this variable only to ecm.eclass?

> 
> Most of the crashing tests are a result of kde-frameworks/kjs being built 
> with Clang.
> I have opened a bug report about this on bugs.kde.org [2].
> 
> Hopefully this is an acceptable solution. I have submitted a corresponding 
> GitHub PR [3].
> Cheers
> 
> [1]: 
> https://userbase.kde.org/KDE_System_Administration/Environment_Variables#KDE_DEBUG
> [2]: https://bugs.kde.org/show_bug.cgi?id=444003#c5
> [3]: https://github.com/gentoo/gentoo/pull/22643
> 
> James Beddek (1):
>   ecm.eclass: set KDE_DEBUG=1 for ecm_src_test
> 
>  eclass/ecm.eclass | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 


-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

2021-10-03 Thread Alexey Sokolov
03.10.2021 07:58, Fabian Groffen пишет:
> 
> FWIW, I like this one.  Perhaps even with lowercase
> 
> make[4]: leaving directory src
> q* soname lacks version
> e* failed to die
> 

For me this reads as some kind of censorship to remove profanities from
the output; and my mind is trying to reconstruct what profanity it was...


-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] News Item for uClibc-ng deprecation

2021-08-17 Thread Alexey Sokolov
17.08.2021 12:40, Anthony G. Basile пишет:
> Hi everyone,
> 
> Can I get feedback on the following news item?  (BTW, thanks soap)
> 
> Title: uClibc-ng retirement on 2023/01/01
> Author: Anthony G. Basile 
> Posted: 2021-08-15
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/uclibc/*
> 
> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> noone has volunteered to step up maintenance or expressed interest in
> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> profiles, which will be removed on 2023/01/01. For parties interested in

2023-01-01 please.

> an alternative libc, consider moving to musl, which is supported.
> 
> Gentoo continues to wholeheartedly support musl and is focusing its
> efforts in that area.
> 
> Resources:
> - https://wiki.gentoo.org/wiki/Project:Hardened_musl
> - https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches)
> - #gentoo-hardened (IRC channel on irc.libera.chat) for support and
> discussion
> 
> 


-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] [PATCH v2] 2021-08-01-tcpd-disabled: Remove USE=tcpd from make.defaults

2021-07-29 Thread Alexey Sokolov
29.07.2021 21:40, David Seifert пишет:
> Signed-off-by: David Seifert 
> ---
>  .../2021-08-01-tcpd-disabled.en.txt   | 68 +++
>  1 file changed, 68 insertions(+)
>  create mode 100644 2021-08-01-tcpd-disabled/2021-08-01-tcpd-disabled.en.txt
> 
> diff --git a/2021-08-01-tcpd-disabled/2021-08-01-tcpd-disabled.en.txt 
> b/2021-08-01-tcpd-disabled/2021-08-01-tcpd-disabled.en.txt
> new file mode 100644
> index 000..977be80
> --- /dev/null
> +++ b/2021-08-01-tcpd-disabled/2021-08-01-tcpd-disabled.en.txt
> @@ -0,0 +1,68 @@
> +Title: USE=tcpd no longer globally enabled
> +Author: David Seifert 
> +Posted: 2021-08-01
> +Revision: 1
> +News-Item-Format: 2.0
> +Display-If-Profile: default/linux/*
> +Display-If-Installed: net-analyzer/argus-clients[tcpd]
> +Display-If-Installed: net-ftp/proftpd[tcpd]
> +Display-If-Installed: app-admin/conserver[tcpd]
> +Display-If-Installed: app-admin/prelude-manager[tcpd]
> +Display-If-Installed: app-admin/qpage[tcpd]
> +Display-If-Installed: app-admin/syslog-ng[tcpd]
> +Display-If-Installed: app-backup/bacula[tcpd]
> +Display-If-Installed: app-backup/bareos[tcpd]
> +Display-If-Installed: app-misc/mosquitto[tcpd]
> +Display-If-Installed: dev-libs/yaz[tcpd]
> +Display-If-Installed: gnome-base/gdm[tcpd]
> +Display-If-Installed: mail-mta/exim[tcpd]
> +Display-If-Installed: mail-mta/sendmail[tcpd]
> +Display-If-Installed: media-sound/pulseaudio[tcpd]
> +Display-If-Installed: net-analyzer/argus[tcpd]
> +Display-If-Installed: net-analyzer/net-snmp[tcpd]
> +Display-If-Installed: net-analyzer/nrpe[tcpd]
> +Display-If-Installed: net-analyzer/nsca[tcpd]
> +Display-If-Installed: net-analyzer/rrdtool[tcpd]
> +Display-If-Installed: net-fs/netatalk[tcpd]
> +Display-If-Installed: net-fs/nfs-utils[tcpd]
> +Display-If-Installed: net-ftp/atftp[tcpd]
> +Display-If-Installed: net-ftp/tftp-hpa[tcpd]
> +Display-If-Installed: net-ftp/vsftpd[tcpd]
> +Display-If-Installed: net-irc/ngircd[tcpd]
> +Display-If-Installed: net-mail/cyrus-imapd[tcpd]
> +Display-If-Installed: net-mail/dovecot[tcpd]
> +Display-If-Installed: net-mail/mailutils[tcpd]
> +Display-If-Installed: net-mail/tpop3d[tcpd]
> +Display-If-Installed: net-misc/apt-cacher-ng[tcpd]
> +Display-If-Installed: net-misc/ser2net[tcpd]
> +Display-If-Installed: net-misc/socat[tcpd]
> +Display-If-Installed: net-misc/sslh[tcpd]
> +Display-If-Installed: net-misc/stunnel[tcpd]
> +Display-If-Installed: net-misc/usbip[tcpd]
> +Display-If-Installed: net-nds/openldap[tcpd]
> +Display-If-Installed: net-nds/rpcbind[tcpd]
> +Display-If-Installed: net-nds/tac_plus[tcpd]
> +Display-If-Installed: net-proxy/dante[tcpd]
> +Display-If-Installed: net-vpn/ocserv[tcpd]
> +Display-If-Installed: net-vpn/pptpd[tcpd]
> +Display-If-Installed: sci-libs/dcmtk[tcpd]
> +Display-If-Installed: sys-apps/linux-misc-apps[tcpd]
> +Display-If-Installed: sys-apps/xinetd[tcpd]
> +Display-If-Installed: sys-fs/quota[tcpd]
> +Display-If-Installed: sys-power/nut[tcpd]
> +
> +On 2021-11-01, we will remove USE="tcpd" from the globally default
> +enabled USE flags (bug #805077). USE="tcpd" usually enables

Please make the bug a full bug URL; such short form can be very
surprising for someone not familiar with gentoo development

> +sys-apps/tcp-wrappers for an ad hoc firewall based on /etc/hosts.allow
> +and /etc/hosts.deny.
> +
> +The Base System project has come to the conclusion that 24 years after
> +the last upstream release, tcp-wrappers is not suitable for a default
> +configuration in 2021 anymore. Other distributions have completely
> +removed support at this point. We strongly recommend you switch to more
> +modern packet filters, such as BPF, nftables, or iptables. If you rely
> +on tcp-wrappers, you can re-enable the flag, see
> +
> +  https://wiki.gentoo.org/wiki//etc/portage/package.use
> +
> +for package-specific ways to re-enable tcp-wrappers.
> 


-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] Guarantees of unstable architectures

2021-07-26 Thread Alexey Sokolov
26.07.2021 17:23, Marek Szuba пишет:
> Dear everyone,
> 
> During the open-floor part of this month's Council meeting I asked
> whether there is any official policy regarding what is or is not
> guaranteed for hardware architectures we do not consider stable in
> Gentoo. For reference, according to the current version of
> profiles/arches.desc (commit 7bdebec50c44c0222bf76334c34926b593e94dd4,
> dated 2021-04-05) this means: alpha, ia64, m68k, mips, riscv, s390,
> and all Prefix arches.

Only the non-RAP one (amd64-linux etc). The prefix installation on amd64
now supports using stable amd64 keyword: https://bugs.gentoo.org/759424

> 
> As it turns out, we do not in fact have any such policy. On the other
> hand, during my time as a Gentoo developer I have heard from other
> developers a fairly wide range of opinions on the subject - from
> insisting on clean QA results, passing tests etc. regardless of whether
> an arch is stable or not to assuming we guarantee nothing for unstable
> arches.
> 
> Anyway, it has been decided that it makes sense to discuss this on the
> mailing list before making it a Council matter. Therefore - what do you
> all think here?
> 


-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] [PATCH 3/3] 2021-07-21-libxcrypt-migration: new news item for libxcrypt migration changes

2021-07-21 Thread Alexey Sokolov
Instead of removing the translation, can it be updated?
Here's the new text to append:

Обратите внимание: если последний раз вы меняли пароль до ~2008 года, он
может использовать в /etc/shadow слабую хэш-функцию, такую как md5crypt.
При этом дефект в PAM [0][1] может помешать вам войти в систему.
Мы рекомендуем вам сменить пароль, чтобы он использовал современные
хэши. Данный дефект был исправлен в новой версии PAM, добавленной в дерево.

В некоторых случаях Portage может попытаться пересобрать некоторые
пакеты в неправильном порядке [2]. Если какой-то пакет не собирается,
попробуйте сначала обновить libcrypt и libxcrypt:

# emerge -v1 virtual/libcrypt sys-libs/libxcrypt

А затем продолжите обновление системы с помощью опции Portage
"--keep-going=y".

Дополнительные сведения и советы можно найти здесь:
* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation
* https://bugs.gentoo.org/699422

[0] https://bugs.gentoo.org/802267
[1] https://bugs.gentoo.org/802807
[2] https://bugs.gentoo.org/802210

20.07.2021 22:32, Sam James пишет:
> Bug: https://bugs.gentoo.org/699422
> Signed-off-by: Sam James 
> ---
>  .../2021-06-30-libxcrypt-migration.ru.txt | 47 ---
>  .../2021-07-21-libxcrypt-migration.en.txt |  4 +-
>  2 files changed, 2 insertions(+), 49 deletions(-)
>  delete mode 100644 
> 2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt
>  rename 2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt 
> => 2021-07-21-libxcrypt-migration/2021-07-21-libxcrypt-migration.en.txt (98%)
> 
> diff --git 
> a/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt 
> b/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt
> deleted file mode 100644
> index d52db11..000
> --- a/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt
> +++ /dev/null
> @@ -1,47 +0,0 @@
> -Title: Миграция в ~arch с glibc[crypt] на libxcrypt
> -Author: Andreas K. Hüttel 
> -Author: Sam James 
> -Translator: Alexey Sokolov 
> -Posted: 2021-06-30
> -Revision: 1
> -News-Item-Format: 2.0
> -
> -Реализация библиотеки libcrypt.so в glibc давно устарела и скоро
> -будет удалена.
> -
> -Прочие дистрибутивы годы назад уже переключились на внешнюю
> -реализацию под названием libxcrypt. Мы решили последовать их примеру
> -и тоже переключиться на libxcrypt. Вначале изменения затронут системы
> -на ~arch.
> -
> -Это будет обычное обновление, и, скорее всего, вам не нужно будет
> -предпринимать никаких действий, и проблем возникнуть не должно.
> -
> -Однако, мы рекомендуем сперва *полностью* обновить систему.
> -Это стандартная рекомендация, но в этом конкретном случае
> -более простой граф зависимостей поможет portage вычислить
> -порядок обновлений.
> -
> -Так что, чтобы упростить процесс обновления, пожалуйста,
> -обновите систему сейчас, до начала самой миграции.
> -
> -Для пользователей ~arch изменение произойдёт 14 июля 2021,
> -пользователи стабильной ветки перейдут на libxcrypt позже.
> -
> -Если по какой-либо причине вы *не* хотите пока переходить
> -на libxcrypt (всего лишь отлагая неизбежное), выполните
> -следующие действия:
> -* размаскируйте и включите USE-флаг crypt пакета sys-libs/glibc
> -* замаскируйте USE-флаг system пакета sys-libs/libxcrypt
> -* замаскируйте >=virtual/libcrypt-2
> -
> -Если вы хотите перейти на libxcrypt уже, точная процедура
> -описана в wiki (см. ниже), но суть такая:
> -* принудительно выключите USE-флаг crypt пакета sys-libs/glibc
> -* размаскируйте USE-флаги system и, если требуется, split-usr
> -  пакета sys-libs/libxcrypt
> -* размаскируйте ~virtual/libcrypt-2
> -
> -Дополнительные сведения можно найти здесь:
> -* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation
> -* https://bugs.gentoo.org/699422
> diff --git 
> a/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt 
> b/2021-07-21-libxcrypt-migration/2021-07-21-libxcrypt-migration.en.txt
> similarity index 98%
> rename from 
> 2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt
> rename to 2021-07-21-libxcrypt-migration/2021-07-21-libxcrypt-migration.en.txt
> index fb16a29..1a9ea96 100644
> --- a/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt
> +++ b/2021-07-21-libxcrypt-migration/2021-07-21-libxcrypt-migration.en.txt
> @@ -1,8 +1,8 @@
>  Title: migrating from glibc[crypt] to libxcrypt in ~arch
>  Author: Andreas K. Hüttel 
>  Author: Sam James 
> -Posted: 2021-06-30
> -Revision: 2
> +Posted: 2021-07-21
> +Revision: 1
>  News-Item-Format: 2.0
>  
>  The implementation of libcrypt.so within glibc has been deprecated
> 


-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] [PATCH] Add 2021-06-30-libxcrypt-migration

2021-07-01 Thread Alexey Sokolov
Hi, Russian translation attached.
>From eba38cc083c51fe6e1325920a8c976b8ae697a1e Mon Sep 17 00:00:00 2001
From: Alexey Sokolov 
Date: Thu, 1 Jul 2021 23:49:22 +0100
Subject: [PATCH] Translate libxcrypt news to Russian

Bug: https://bugs.gentoo.org/699422
Signed-off-by: Alexey Sokolov 
---
 .../2021-06-30-libxcrypt-migration.ru.txt | 47 +++
 1 file changed, 47 insertions(+)
 create mode 100644 2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt

diff --git a/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt b/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt
new file mode 100644
index 000..d52db11
--- /dev/null
+++ b/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt
@@ -0,0 +1,47 @@
+Title: Миграция в ~arch с glibc[crypt] на libxcrypt
+Author: Andreas K. Hüttel 
+Author: Sam James 
+Translator: Alexey Sokolov 
+Posted: 2021-06-30
+Revision: 1
+News-Item-Format: 2.0
+
+Реализация библиотеки libcrypt.so в glibc давно устарела и скоро
+будет удалена.
+
+Прочие дистрибутивы годы назад уже переключились на внешнюю
+реализацию под названием libxcrypt. Мы решили последовать их примеру
+и тоже переключиться на libxcrypt. Вначале изменения затронут системы
+на ~arch.
+
+Это будет обычное обновление, и, скорее всего, вам не нужно будет
+предпринимать никаких действий, и проблем возникнуть не должно.
+
+Однако, мы рекомендуем сперва *полностью* обновить систему.
+Это стандартная рекомендация, но в этом конкретном случае
+более простой граф зависимостей поможет portage вычислить
+порядок обновлений.
+
+Так что, чтобы упростить процесс обновления, пожалуйста,
+обновите систему сейчас, до начала самой миграции.
+
+Для пользователей ~arch изменение произойдёт 14 июля 2021,
+пользователи стабильной ветки перейдут на libxcrypt позже.
+
+Если по какой-либо причине вы *не* хотите пока переходить
+на libxcrypt (всего лишь отлагая неизбежное), выполните
+следующие действия:
+* размаскируйте и включите USE-флаг crypt пакета sys-libs/glibc
+* замаскируйте USE-флаг system пакета sys-libs/libxcrypt
+* замаскируйте >=virtual/libcrypt-2
+
+Если вы хотите перейти на libxcrypt уже, точная процедура
+описана в wiki (см. ниже), но суть такая:
+* принудительно выключите USE-флаг crypt пакета sys-libs/glibc
+* размаскируйте USE-флаги system и, если требуется, split-usr
+  пакета sys-libs/libxcrypt
+* размаскируйте ~virtual/libcrypt-2
+
+Дополнительные сведения можно найти здесь:
+* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation
+* https://bugs.gentoo.org/699422
-- 
2.31.1



Re: [gentoo-dev] Declare the type of source

2021-06-28 Thread Alexey Sokolov
Hi

28.06.2021 14:00, Agostino Sarubbo пишет:
> Hello all,
> 
> long story short:
> 
> when there is a major change (new gcc, new libc, and so on), tinderbox takes 
> a 
> lot of time to test the entire tree.
> 
> Let's do a practical example: 
> A new version of sys-devel/gcc is added to the tree.
> 
> There is no way to know how much packages compiles C/C++ code, so the easiest 
> way is compile the entire tree.
> 
> Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or 
> similar, or in metadata.xml if you prefer ) and with a tool like equery/eix 
> we 
> are able to get the list of all packages that compiles C code.
> 
> The same thing applies to other languages like python, ruby, go and so on 
> where compile the dev-$language category covers a lot of packages, but there 
> will be always other ebuilds that uses $language in other categories.
> 
> What do you think?
> 
> Agostino
> 
> 

I can easily imagine a scenario where some pure perl package would fail
tests because one of indirect dependencies was compiled with clang
instead of gcc.

-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] Packages up for grabs

2021-06-13 Thread Alexey Sokolov


>   dev-cpp/yaml-cpp

I'll take this


-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] [PATCH news v3] Add Python 3.9 news item

2021-05-06 Thread Alexey Sokolov
Oops, I thought I did that. Fixed.

чт, 6 мая 2021 г. в 07:57, Michał Górny :
>
> On Thu, 2021-05-06 at 01:13 +0100, Alexey Sokolov wrote:
> > Here's the Russian version
> >
>
> Could you include a copyright signoff, please?  This is pretty major
> work.
>
> --
> Best regards,
> Michał Górny
>
>
>
From 1bd30ecd61096a683f71533669c539d42b655bfe Mon Sep 17 00:00:00 2001
From: Alexey Sokolov 
Date: Thu, 6 May 2021 01:05:38 +0100
Subject: [PATCH] Translate python3-9 to Ru

Signed-off-by: Alexey Sokolov 
---
 .../2021-05-05-python3-9.ru.txt   | 113 ++
 1 file changed, 113 insertions(+)
 create mode 100644 2021-05-05-python3-9/2021-05-05-python3-9.ru.txt

diff --git a/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt b/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt
new file mode 100644
index 000..cfef9d4
--- /dev/null
+++ b/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt
@@ -0,0 +1,113 @@
+Title: Python 3.9 станет питоном по умолчанию 2021-06-01
+Author: Michał Górny 
+Translator: Alexey Sokolov 
+Posted: 2021-05-05
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: dev-lang/python:3.7
+Display-If-Installed: dev-lang/python:3.8
+
+1 июня 2021 года мы собираемся переключить Python по умолчанию на системах
+Gentoo с версии 3.8 на версию 3.9.  Если вы не меняли значения PYTHON_TARGETS и
+PYTHON_SINGLE_TARGET, изменение затронет систему сразу: пакетный менеджер
+попытается применить изменение при следующем обновлении системы.
+
+Если же вы изменили эти значения, предпочитаете более безопасный подход, или
+при обновлении возникли проблемы, продолжайте читать.
+
+Пожалуйста, обратите внимание, что метод обновления по умолчанию переключает
+пакеты на новую версию питона, когда они пересобираются.  Это означает, что для
+пересборки пакета все зависимые пакеты должны уже поддерживать новую версию, и
+некоторые программы временно могут не находить свои зависимости во время
+обновления (однако, скорее всего, уже запущенные программы будут в порядке).
+
+Если PYTHON_TARGETS или PYTHON_SINGLE_TARGET объявлены в вашем make.conf,
+пожалуйста, удалите их оттуда, потому что они будут конфликтовать с показанными
+далее кусками из package.use.  Мы не рекомендуем использовать make.conf для
+этих переменных, поскольку они мешают применяться значениям по умолчанию для
+пакетов, где это необходимо.  В этой новости мы подразумеваем, что вы
+используете /etc/portage/package.use или его эквивалент для вашего пакетного
+менеджера.
+
+У вас есть выбор из следующих вариантов:
+
+1. Если вы хотите, чтобы питон обновлялся сам, вы можете удалить объявленные
+   PYTHON_TARGETS и PYTHON_SINGLE_TARGET. Когда значения по умолчанию
+   изменятся, пакетный менеджер должен сам всё обновить. Но если возникнут
+   проблемы, вам всё равно может прийтись запустить команды обновления.
+
+2. Если вы хотите пока отложить обновление, вы можете явно указать старые
+   значения в package.use.
+
+3. Если вы хотите обновиться раньше, вы можете явно указать новые значения и
+   запустить команды обновления.
+
+4. Если вы хотите более безопасный подход, у которого меньше шансов поломать
+   пакеты во время обновления, вы можете произвести последовательность шагов,
+   описанных далее.
+
+5. Наконец, вы можете произвольным образом комбинировать значения
+   PYTHON_TARGETS и PYTHON_SINGLE_TARGET.
+
+
+Откладывание обновления
+===
+Чтобы отложить обновление, явно укажите старые значения:
+
+*/* PYTHON_TARGETS: -* python3_8
+*/* PYTHON_SINGLE_TARGET: -* python3_8
+
+Это заставит систему использовать Python 3.8 и предотвратит будущие обновления.
+Однако, такое решение сойдёт только на несколько месяцев; когда-нибудь вам
+всё-таки нужно будет обновиться.
+
+
+Принудительное обновление
+=
+Чтобы обновиться до Python 3.9 раньше, явно укажите новые значения:
+
+*/* PYTHON_TARGETS: -* python3_9
+*/* PYTHON_SINGLE_TARGET: -* python3_9
+
+При этом важно не забыть удалить эти строки после смены значений по умолчанию,
+иначе они помешают будущим автоматическим обновлениям до следующих версий
+питона.
+
+
+Процедура безопасного обновления
+
+Более безопасный подход такой: сначала добавляется в систему поддержка Python
+3.9, а затем удаляется Python 3.8.  Однако, все затронутые пакеты будут
+пересобраны дважды, и это заметно дольше.
+
+Сначала включите и Python 3.8, и Python 3.9 и запустите команды обновления:
+
+*/* PYTHON_TARGETS: -* python3_8 python3_9
+*/* PYTHON_SINGLE_TARGET: -* python3_8
+
+Затем замените PYTHON_SINGLE_TARGET и ещё раз запустите команды:
+
+*/* PYTHON_TARGETS: -* python3_8 python3_9
+*/* PYTHON_SINGLE_TARGET: -* python3_9
+
+Наконец, вот окончательная версия, и не забудьте запустить команды:
+
+*/* PYTHON_TARGETS: -* python3_9
+*/* PYTHON_SINGLE_TARGET: -* python3_9
+
+После смены значений по умолчанию вы можете удалить эти настройки. Или же вы

Re: [gentoo-dev] [PATCH news v3] Add Python 3.9 news item

2021-05-05 Thread Alexey Sokolov
Here's the Russian version

пн, 3 мая 2021 г. в 21:35, Sam James :
>
>
>
> > On 3 May 2021, at 21:18, Michał Górny  wrote:
> >
> > On Mon, 2021-05-03 at 19:06 +0100, Sam James wrote:
> >> [snip]
> >
> > I want to avoid it on the top, so people don't do it prematurely before
> > reading their options.
> >
>
> Good point - and I can’t complain, given I partly made that comment earlier ;)
>
> LGTM then.
>
> > --
> > Best regards,
> > Michał Górny
>
From 757517fe67e353f44a8739237a552726ae7c221f Mon Sep 17 00:00:00 2001
From: Alexey Sokolov 
Date: Thu, 6 May 2021 01:05:38 +0100
Subject: [PATCH] Translate python3-9 to Ru

---
 .../2021-05-05-python3-9.ru.txt   | 113 ++
 1 file changed, 113 insertions(+)
 create mode 100644 2021-05-05-python3-9/2021-05-05-python3-9.ru.txt

diff --git a/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt b/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt
new file mode 100644
index 000..cfef9d4
--- /dev/null
+++ b/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt
@@ -0,0 +1,113 @@
+Title: Python 3.9 станет питоном по умолчанию 2021-06-01
+Author: Michał Górny 
+Translator: Alexey Sokolov 
+Posted: 2021-05-05
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: dev-lang/python:3.7
+Display-If-Installed: dev-lang/python:3.8
+
+1 июня 2021 года мы собираемся переключить Python по умолчанию на системах
+Gentoo с версии 3.8 на версию 3.9.  Если вы не меняли значения PYTHON_TARGETS и
+PYTHON_SINGLE_TARGET, изменение затронет систему сразу: пакетный менеджер
+попытается применить изменение при следующем обновлении системы.
+
+Если же вы изменили эти значения, предпочитаете более безопасный подход, или
+при обновлении возникли проблемы, продолжайте читать.
+
+Пожалуйста, обратите внимание, что метод обновления по умолчанию переключает
+пакеты на новую версию питона, когда они пересобираются.  Это означает, что для
+пересборки пакета все зависимые пакеты должны уже поддерживать новую версию, и
+некоторые программы временно могут не находить свои зависимости во время
+обновления (однако, скорее всего, уже запущенные программы будут в порядке).
+
+Если PYTHON_TARGETS или PYTHON_SINGLE_TARGET объявлены в вашем make.conf,
+пожалуйста, удалите их оттуда, потому что они будут конфликтовать с показанными
+далее кусками из package.use.  Мы не рекомендуем использовать make.conf для
+этих переменных, поскольку они мешают применяться значениям по умолчанию для
+пакетов, где это необходимо.  В этой новости мы подразумеваем, что вы
+используете /etc/portage/package.use или его эквивалент для вашего пакетного
+менеджера.
+
+У вас есть выбор из следующих вариантов:
+
+1. Если вы хотите, чтобы питон обновлялся сам, вы можете удалить объявленные
+   PYTHON_TARGETS и PYTHON_SINGLE_TARGET. Когда значения по умолчанию
+   изменятся, пакетный менеджер должен сам всё обновить. Но если возникнут
+   проблемы, вам всё равно может прийтись запустить команды обновления.
+
+2. Если вы хотите пока отложить обновление, вы можете явно указать старые
+   значения в package.use.
+
+3. Если вы хотите обновиться раньше, вы можете явно указать новые значения и
+   запустить команды обновления.
+
+4. Если вы хотите более безопасный подход, у которого меньше шансов поломать
+   пакеты во время обновления, вы можете произвести последовательность шагов,
+   описанных далее.
+
+5. Наконец, вы можете произвольным образом комбинировать значения
+   PYTHON_TARGETS и PYTHON_SINGLE_TARGET.
+
+
+Откладывание обновления
+===
+Чтобы отложить обновление, явно укажите старые значения:
+
+*/* PYTHON_TARGETS: -* python3_8
+*/* PYTHON_SINGLE_TARGET: -* python3_8
+
+Это заставит систему использовать Python 3.8 и предотвратит будущие обновления.
+Однако, такое решение сойдёт только на несколько месяцев; когда-нибудь вам
+всё-таки нужно будет обновиться.
+
+
+Принудительное обновление
+=
+Чтобы обновиться до Python 3.9 раньше, явно укажите новые значения:
+
+*/* PYTHON_TARGETS: -* python3_9
+*/* PYTHON_SINGLE_TARGET: -* python3_9
+
+При этом важно не забыть удалить эти строки после смены значений по умолчанию,
+иначе они помешают будущим автоматическим обновлениям до следующих версий
+питона.
+
+
+Процедура безопасного обновления
+
+Более безопасный подход такой: сначала добавляется в систему поддержка Python
+3.9, а затем удаляется Python 3.8.  Однако, все затронутые пакеты будут
+пересобраны дважды, и это заметно дольше.
+
+Сначала включите и Python 3.8, и Python 3.9 и запустите команды обновления:
+
+*/* PYTHON_TARGETS: -* python3_8 python3_9
+*/* PYTHON_SINGLE_TARGET: -* python3_8
+
+Затем замените PYTHON_SINGLE_TARGET и ещё раз запустите команды:
+
+*/* PYTHON_TARGETS: -* python3_8 python3_9
+*/* PYTHON_SINGLE_TARGET: -* python3_9
+
+Наконец, вот окончательная версия, и не забудьте запустить команды:
+

Re: [gentoo-dev] [News item review] V2 Chromium access to Google services

2021-03-08 Thread Alexey Sokolov
Hi, Russian translation follows.

Title: Доступ браузера Chromium к сервисам Google
Author: Stephan Hartmann 
Translator: Alexey Sokolov 
Posted: 2021-03-09
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: www-client/chromium

С 15 марта 2021 команда Google Chrome ограничит доступ к Google API и службам,
зарезервированным для использования самим Google. Это означает, что
пользователи больше не смогут войти в учётную запись Google и потому у них не
будет доступа к, например, Chrome Sync.

Поэтому нам приходится удалить из www-client/chromium Client ID и ключи. Мы уже
удалили их из =www-client/chromium-89.0.4389.82, остальные версии будут
обновлены в ближайшем будущем.

Если вам нужен доступ к этим API, вам нужно либо перейти на
www-client/google-chrome{-beta,-unstable}, либо установить ваши собственные
ключи [1], что, однако, предназначено только для разработки. Инструкцию по
созданию и использованию собственных ключей можно найти здесь [2].

[1]
https://groups.google.com/a/chromium.org/g/chromium-dev/c/jgy5pcJ7np8/m/p3j_4b6vBQAJ
[2] https://www.chromium.org/developers/how-tos/api-keys

пн, 8 мар. 2021 г. в 19:01, Stephan Hartmann :
>
> Hi,
>
> updated based on previous suggestions.
>
> ```
> Title: Chromium access to Google services
> Author: Stephan Hartmann 
> Content-Type: text/plain
> Posted: 2021-03-09
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: www-client/chromium
>
> Starting March 15th, 2021 Google Chrome Team will restrict access to
> Google APIs and services that are reserved for Google use only. This
> means that users are no longer able to login into their Google Accounts
> which disables access to for example Chrome Sync.
>
> As a consequence we have to remove Client ID and secret from all
> www-client/chromium ebuilds. This change has already been done for
> =www-client/chromium-89.0.4389.82. Other versions will be updated
> shortly.
>
> If you need one of the Google use only APIs, then you either have to
> switch to www-client/google-chrome{-beta,-unstable} or setup your own
> keys [1]. However, the latter is only intended for development.
> Documentation on how to generate and use own keys can be found in [2].
>
> [1]
> https://groups.google.com/a/chromium.org/g/chromium-dev/c/jgy5pcJ7np8/m/p3j_4b6vBQAJ
> [2] https://www.chromium.org/developers/how-tos/api-keys
> ```
>
> Best regards,
>
> Stephan
>


Re: [gentoo-dev] feature request: packages.gentoo.org

2021-02-12 Thread Alexey Sokolov
Hi
There is a Packages component at
https://bugs.gentoo.org/enter_bug.cgi?product=Websites for reports
like this

пт, 12 февр. 2021 г. в 07:10, Jaco Kroon :

>
> Hi,
>
> Firstly:  I was aware of packages.gentoo.org - but only really discovered it 
> in the week - THANK YOU VERY MUCH FOR THIS.
>
> Not sure whether this is the best place for my request, so if not, please 
> feel free to bat me in the right direction.
>
> https://packages.gentoo.org/packages/net-misc/asterisk (example) refers.
>
> I'm the (proxy) maintainer.
>
> The above URL merely states:
>
> It seems that version 18.2.0 is available upstream, while the latest version 
> in the Gentoo tree is 16.15.1.
>
> This is correct.  Just looking a little down, it's noted there are two 
> versions currently in tree:
>
> 16.15.1-r2 : 0
> 13.38.1-r2 : 0
>
> What's not indicated, there are subslots (13 and 16 respectively).
>
> eshowkw (app-portage/gentoolkit) shows:
>
> Keywords for net-misc/asterisk:
>   | |   u  |
>   | a   a p s a   r |   n  |
>   | m   r h   p p   s l i i m m | e u s| r
>   | d a m p p c a x 3 p a s 6 i | a s l| e
>   | 6 r 6 p p 6 r 8 9 h 6 c 8 p | p e o| p
>   | 4 m 4 a c 4 c 6 0 a 4 v k s | i d t| o
> --+-+--+---
>13.38.1-r2 | + ~ ~ o ~ ~ o + o o o o o o | 7 o 0/13 | gentoo
> --+-+--+---
> [I]16.15.1-r2 | ~ ~ ~ o ~ ~ o ~ o o o o o o | 7 o 0/16 | gentoo
>
> Which is currently as intended (yea, I'm behind the times - stable and 
> working in this case over bleeding edge - and nobody other than me is yet 
> pushing me to stable /16, although I have a bug request to package 18 which I 
> intend to start work on today hopefully since I'm working on asterisk stuff 
> for business purposes today anyway).
>
> 13 is security only release now, and 16 and 18 are the primary branches where 
> 16 is more intended as stable and more fluctuations on 18 still (which 
> precludes me from using it for our company just yet).
>
> Point being, it would be great if packages.gentoo.org could indicate that in 
> above cases as follows:
>
> 18.2.0 is available, which is correct, and desired, but if it could also 
> indicate that for the 16 branch there is currently a version of 16.16.0 
> available, and for 13 things are up to date.
>
> Would be useful too to indicate that certain branches (eg, 17 in the asterisk 
> case will not be packaged due to being primarily development branches, or at 
> the very least, will not be considered for stabling)
>
> In other words, guessing I'm looking for some form of "branched versions" 
> support here.
>
> I know security already has some work around subslots as it was the sec team 
> that requested me to add subslots to net-misc/asterisk.
>
> And yes ... looks like repology does have a few issues around branches too:  
> https://repology.org/project/asterisk/cves?version=13.38.1
>
> So I would completely understand if it's not possible to deal with this.  As 
> per 
> https://archives.gentoo.org/gentoo-dev/message/b793f4da5a5b5e20a063ea431500a820
>  there are certain configs that can go into 
> https://gitweb.gentoo.org/sites/soko-metadata.git/ - however, not being a 
> core developer, I don't have (nor am I requesting) access here.  May I 
> suggest that in-package metadata (ie, metadata.xml, or even inside the 
> ebuilds) might be a better location for some of this configuration if 
> possible, and if it makes sense?  For me the advantage is that as a PM I can 
> submit the required information via PR.
>
> A description of the branch structure may be more suitable here anyway, 
> because that way other tools can leverage it too?
>
> Then again, perhaps just looking at the subslots as already available is good 
> enough, in the case of the packages I work on this would indeed be adequate, 
> but it may not be for other packages.
>
> Looking at repology.org itself, I'm not sure my request is trivial, and I'm 
> not going to ask tons of effort be put into this, but perhaps an interesting 
> challenge for someone at some point.
>
> Kind Regards,
> Jaco



Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-10 Thread Alexey Sokolov
ср, 10 февр. 2021 г. в 01:16, Tim Harder :
>
> On 2021-02-09 Tue 17:51, Benda Xu wrote:
> > I am wondering how useable pkgcore is on alpha, hppa, etc.  Maybe it's
> > time for us to plan for a Gentoo without essential Python dependency.
>
> Just to keep misinformation down, pkgcore currently has nothing to do
> with rust as it's implemented in python due to basically being deemed
> portage-ng when it forked ~15 years ago. It previously did have some
> extensions written in C which have mostly been removed in the current
> day from CPython catching up in a number of areas.
>
> That being said, alternative languages and related support has been
> looked at for a number of reasons/features and development could move in
> that direction, but hasn't yet in a public fashion.
>
> Tim
>

Another far-fetched option is to compile CPython to WebAssembly+WASI
[1] (even if CPython itself will require Rust in future), and run it
on the non-Rust-supported architecture via an interpreter [2].

If this works at all, bootstrap will probably be not trivial. And such
version of interpreted python may need to be added to PYTHON_TARGETS
to enable testing of this on more usual architectures like amd64.

[1] https://wasi.dev/
[2] https://github.com/wasm3/wasm3



Re: [gentoo-dev] New project: binhost

2021-02-10 Thread Alexey Sokolov
ср, 10 февр. 2021 г. в 19:12, Rich Freeman :
>
> On Wed, Feb 10, 2021 at 12:57 PM Andreas K. Hüttel  
> wrote:
> >
> > * what portage features are still needed or need improvements (e.g. binpkg
> > signing and verification)
> > * how should hosting look like
>
> Some ideas for portage enhancements:
>
> 1.  Ability to fetch binary packages from some kind of repo.
> 2.  Ability to have multiple binary packages co-exist in a repo (local
> or remote) with different build attributes (arch, USE, CFLAGS,
> DEPENDS, whatever).
> 3.  Ability to pick the most appropriate binary packages to use based
> on user preferences (with a mix of hard and soft preferences).
>
> One idea I've had around how #2-3 might be implemented is:
> 1.  Binary packages already contain data on how they were built (USE
> flags, dependencies, etc).  Place this in a file using a deterministic
> sorting/etc order so that two builds with the same settings will have
> the same results.
> 2.  Generate a hash of the file contents - this can go in the filename
> so that the file can co-exist with other files, and be located
> assuming you have a full matching set of metadata.
> 3.  Start dropping attributes from the file based on a list of
> priorities and generate additional hashes.  Create symlinked files to
> the original file using these hashes (overwriting or not existing
> symlinks based on policy).  This allows the binary package to be found
> using either an exact set of attributes or a subset of higher-priority
> attributes.  This is analogous to shared object symlinking.
> 4.  The package manager will look for a binary package first using the
> user's full config, and then by dropping optional elements of the
> config (so maybe it does the search without CFLAGs, then without USE
> flags).  Eventually it aborts based on user prefs (maybe the user only
> wants an exact match, or is willing to accept alternate CFLAGs but not
> USE flags, or maybe anything for the arch is selected.

A related idea: if user could specify which USE-flags are mandatory to
be set, which USE flags are mandatory to be not set, and which can be
either way, it's easier to find the matching binary package with less
constraints, where only some flags match.

> 5.  As always the final selected binary package still gets evaluated
> like any other binary package to ensure it is usable.
>
> Such a system can identify whether a potentially usable file exists
> using only filename, cutting down on fetching.  In the interests of
> avoiding useless fetches we would only carry step 3 reasonably far -
> packages would have to match based on architecture and any dynamic
> linking requirements.  So we wouldn't generate hashes that didn't
> include at least those minimums, and the package manager wouldn't
> search for them.
>
> Obviously you could do more (if you have 5 combinations of use flags,
> look for the set that matches most closely).  That couldn't be done
> using hashes alone in an efficient way.  You could have a small
> manifest file alongside the binary package that could be fetched
> separately if the package manager wants to narrow things down and
> fetch a few of those to narrow it down further.
>
> Or you could skip the hash searching and just fetch all the manifests
> for a particular package/arch and just search all of those, but that
> is more data to transfer just to do a query.  A metadata cache of some
> kind of might be another solution.  Content hashes would probably
> still be useful just to allow co-existence of alternate builds.
>
> --
> Rich
>



Re: [gentoo-dev] [News item review v2] Python preference to follow PYTHON_TARGETS

2021-01-24 Thread Alexey Sokolov
вс, 24 янв. 2021 г. в 12:59, Michał Górny :
>
> Here's v2 with extra 'tl;dr' instructions in first para:
>
> ```
> Title: Python preference to follow PYTHON_TARGETS
> Author: Michał Górny 
> Posted: 2021-01-24
> Revision: 1
> News-Item-Format: 2.0
>
> On 2021-02-01 stable users will switch to a new method of updating
> the preferred Python versions that employs the configuration update
> mechanism in order to follow PYTHON_TARGETS.  We will also deprecate
> and stop installing app-eselect/eselect-python by default.  If you wish
> to use the newest Python version present in your PYTHON_TARGETS, you
> only have to accept configuration changes.  If you wish need
> to customize the behavior, read on.

typo: wish need

>
> Since 2017, /usr/bin/python and the related non-versioned symlinks
> are wrapped through dev-lang/python-exec.  The list of preferred Python
> implementations is stored in /etc/python-exec/python-exec.conf and/or
> per-program /etc/python-exec/.conf configuration files.
> To preserve backwards compatibility, app-eselect/eselect-python remained
> a wrapper that updated this file.
>
> However, this mechanism alone has proven inconvenient to end users who
> had to update python-exec.conf whenever the default PYTHON_TARGETS
> changed.  Thanks to the fallback logic, this was not a major problem
> for software installed via Gentoo packages that always ensure that
> a supported implementation is used.  However, users have reported that
> whenever the preference for /usr/bin/python mismatched their
> PYTHON_TARGETS, their custom scripts would break due to unsatisfied
> dependencies.  This does not follow the principle of least surprise.
>
> For this reason, we have decided to change the default python-exec
> configuration to match PYTHON_TARGETS by default, in the eclass
> preference order, that is from the newest CPython version to oldest,
> with alternative Python implementations coming afterwards.  This change
> will be propagated via the configuration protection mechanism whenever
> dev-lang/python-exec-conf is installed or rebuilt due to PYTHON_TARGETS
> changes.  This will permit the users to interactively confirm
> the updates.
>
> If the new default is not correct for you, please use your preferred
> configuration update tool to discard or edit the new configuration file.
>
> Furthermore, dev-lang/python will no longer attempt to automatically
> update the Python interpreter preference, or pull in eselect-python
> automatically.  If you wish to continue using it, please install it
> manually to ensure that it is not unmerged.

Perhaps add the "emerge" command here, to avoid users to actually
*manually* installing it? That is, not via the ebuild.

The Russian translation follows. Should I post it as a separate file somewhere?

Title: Предпочтения Python будут следовать PYTHON_TARGETS

1 февраля 2021 пользователи стабильной ветки перейдут на новый метод обновления
предпочтительной версии Python, который будет использовать значение переменной
PYTHON_TARGETS и применять механизм обновления конфигураций.  Также мы
объявляем app-eselect/eselect-python устаревшим и по умолчанию перестанем его
устанавливать.  Если вы хотите использовать самую новую версию Python из
указанных в PYTHON_TARGETS, вам надо только принять изменения конфигурации.
Если же вам нужно настроить индивидуальное поведение, продолжайте читать.

С 2017 года /usr/bin/python и тому подобные символические ссылки без версии
являются обёртками с помощью dev-lang/python-exec.  Список предпочтительных
реализаций Python хранится в /etc/python-exec/python-exec.conf и/или в
/etc/python-exec/<программа>.conf для программ с конфигурацией не по умолчанию.
Для обратной совместимости app-eselect/eselect-python остался обёрткой, которая
обновляла этот файл.

Однако сам по себе этот механизм оказался неудобен пользователям, которым
теперь приходилось обновлять python-exec.conf каждый раз, когда менялась
переменная PYTHON_TARGETS.  Благодаря логике запасных вариантов это не было
большой проблемой для программ, установленных из репозитория Gentoo, т.к. они
гарантируют использование поддерживаемой реализации Python.  Но пользователи
сообщали, что, когда предпочтение для /usr/bin/python не совпадало с их
PYTHON_TARGETS, из-за неудовлетворённых зависимостей ломались пользовательские
программы, что противоречит принципу наименьшего удивления.

Поэтому мы решили изменить стандартную настройку python-exec, теперь она будет
совпадать с PYTHON_TARGETS в порядке предпочтения, используемым eclass'ом:
сначала все CPython, начиная с новейшей версии и заканчивая старейшей, затем
другие реализации Python.  Это изменение будет установлено в систему с помощью
механизма защиты конфигураций каждый раз при установке или пересборке
dev-lang/python-exec-conf из-за изменения PYTHON_TARGETS.  При этом у
пользователей будет возможность интерактивно подтвердить данные изменения.

Если новые настройки вам не подходят, пожалуйста, используйте ваш любимый
инструмент обновления 

Re: [gentoo-dev] ml project created

2021-01-13 Thread Alexey Sokolov
Hi, that wiki page says it just got deleted, by you

вт, 12 янв. 2021 г. в 19:24, Alfredo Tupone :
>
> As I have interest on lot of ebuild on dev-ml, and most of them are not
> managed by any project, I have created a project to handle them.
>
> I have build https://wiki.gentoo.org/wiki/Project:Ml tring to revive
> an old ml project.
>
> Any comments?
>
> Alfredo
>



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

2020-12-29 Thread Alexey Sokolov
вт, 29 дек. 2020 г. в 13:33, David Seifert :
>
> On Tue, 2020-12-29 at 13:21 +, Peter Stuge wrote:
> > Michał Górny wrote:
> > > > 2.  Install them into different prefixes (eg /usr/lib/openssl +
> > > > /usr/lib/libressl and have the linker link to a specific version,
> > > > /usr/include/{openssl,libressl} too).
> > >
> > > For the record, this is something I've been wondering about for a
> > > long
> > > time.  However, there are two problems with that: a small one
> > > and a huge one.
> > >
> > > The small problem is that this requires a lot of additional
> > > downstream
> > > work.  I mean, you have to explicitly support the choice in ebuilds,
> > > and this means making things even harder for newcomers.
> >
> > pkg-config/pkgconf and .pc files can help with this part, taking care
> > of all abstraction if/when downstream uses a libressl.pc.
>
> As we have learned from the ncurses[tinfo] debacle, 80% of build systems
> don't use the .pc files, and just guess "-lssl" flags and a bunch of
> include dirs. Hence, this boils down to patching a mountain of build
> systems again, which while being the ultimately correct way, is a pipe
> dream.

If it's the ultimately correct way, such patches can be sent upstream,
regardless of whether libressl stays.

>
> > > The big problem is that (unless I'm mistaken) we won't be able to
> > > load
> > > LibreSSL and OpenSSL to the same executable.  So we'd actually have
> > > to
> > > enforce that the whole link chain links to the same SSL provider,
> > > and effectively land pretty close to where we are now.
> >
> > I'd suggest investigating whether symbol versioning could help with
> > this,
> > or if the only way forward would indeed be to require some symbol
> > mangling/rewriting.
>
> While this sounds like a theoretical solution, it isn't tractable
> because
> 1. We're inventing our own ABI that is incompatible with everyone else's
> 2. We'd have to maintain a huge swamp of downstream patches
> 3. ABI can still break even with perfect symbol versioning
>
>



Re: [gentoo-dev] Applying for package maintenance

2020-11-15 Thread Alexey Sokolov
15.11.2020 10:10, Ivan J. пишет:
> Greetings. I am wondering what is the process to apply for maintaining a
> package in the portage tree that has a "mainainer-needed" entry? More
> specifically, I would like to maintain www-client/surf.
> 

Please see https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers


-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

2020-11-10 Thread Alexey Sokolov
10.11.2020 08:55, Fabian Groffen пишет:
> On 09-11-2020 19:38:28 +0000, Alexey Sokolov wrote:
>> Hi Fabian
>> I tried to migrate my prefix to 17.1, and there are issues.
>>
>> 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an
>> error "/usr/lib is a real directory! was the migration done already?"
> 
> I think unsymlink-lib doesn't have Prefix support, but in addition,
> what unsymlink-lib is trying to achieve, is not a thing perhaps on
> Prefix.
> 
> A prefix system (at least all of mine) doesn't have libXX or lib/XX
> (a.k.a.  multilib) directories.  The /usr-split was long ago removed,
> and thus what we have is:
> 
>   lib -> usr/lib
> 
> Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does
> not exist on Prefix systems.
> 
> Since Prefix is non-multilib by design*, I wonder if unsymlink-lib is
> necessary in the best case, but going to break the Prefix system in the
> worst case.
> 
> What instructed you to perform the migration?  Was it the news-item?  I
> don't think it should apply for Prefix profiles, and perhaps we should
> be happy the tool won't work.

It was the big scary warning about the deprecation whenever I run
emerge. It contains list of steps.

> * non-multilib is a decision dating back a decade or so, which means
>   effectively any Prefix install you encounter should be non-multilib
> 
> 
>> 2) $ unsymlink-lib --root ~/gentoo --migrate --pretend
>> usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate]
>>  [--rollback] [--finish] [--force-rollback]
>>  [--resume-finish] [-P PREFIX] [--hardlink]
>> unsymlink-lib: error: Requested action requires root privileges
>>
>> Well, I worked it around by adding "is_root = True" to unsymlink-lib
> 
> Did it do anything to your system like creating a lib64 directory?  Does
> anything work (because I have doubts on whether your system can still
> find the libs in there now).

Yes. Attaching logs.

> 
>>
>> 3) Step 9 (Rebuild gcc) fails:
>> configure:4372: checking whether the C compiler works
>>
>>
>>
>> configure:4394: x86_64-pc-linux-gnu-gccconftest.c  >&5
>>
>>
>>
>> /home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as:
>> error while loading shared libraries:
>> libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared
> 
> Something like this I was suspecting.  Can you still rollback?  If you
> can, I'd try that and hope it restores your system in working order.

Yeah, don't worry, this is my ebuild-testing chroot. I just did "lxc
restore".


-- 
Best regards,
Alexey "DarthGandalf" Sokolov
Analyzing files installed into lib & lib64...

directories that will be moved to /home/user/gentoo/lib/:
	(+ 0 files)

directories whose contents will be split between /home/user/gentoo/lib/ and /home/user/gentoo/lib64/:

orphan dirs/files (not owned by any package) that will be moved to /home/user/gentoo/lib/:
	gentoo
	modprobe.d
	systemd

orphan dirs/files (not owned by any package) that will be kept in /home/user/gentoo/lib64/:
	ld-2.31.so
	ld-linux-x86-64.so.2
	libBrokenLocale-2.31.so
	libBrokenLocale.so.1
	libSegFault.so
	libanl-2.31.so
	libanl.so.1
	libc-2.31.so
	libc.so.6
	libcrypt-2.31.so
	libcrypt.so.1
	libdl-2.31.so
	libdl.so.2
	libkmod.so.2
	libkmod.so.2.3.5
	libm-2.31.so
	libm.so.6
	libmemusage.so
	libmvec-2.31.so
	libmvec.so.1
	libnsl-2.31.so
	libnsl.so.1
	libnss_compat-2.31.so
	libnss_compat.so.2
	libnss_db-2.31.so
	libnss_db.so.2
	libnss_dns-2.31.so
	libnss_dns.so.2
	libnss_files-2.31.so
	libnss_files.so.2
	libnss_hesiod-2.31.so
	libnss_hesiod.so.2
	libpcprofile.so
	libpthread-2.31.so
	libpthread.so.0
	libresolv-2.31.so
	libresolv.so.2
	librt-2.31.so
	librt.so.1
	libthread_db-1.0.so
	libthread_db.so.1
	libutil-2.31.so
	libutil.so.1

directories that will be moved to /home/user/gentoo/usr/lib/:
	(+ 0 files)

directories whose contents will be split between /home/user/gentoo/usr/lib/ and /home/user/gentoo/usr/lib64/:

orphan dirs/files (not owned by any package) that will be moved to /home/user/gentoo/usr/lib/:
	Mcrt1.o
	Scrt1.o
	audit
	binutils
	cmake
	crt1.o
	crti.o
	crtn.o
	debug
	engines-1.1
	gawk
	gcc
	gconv
	gcrt1.o
	gettext
	glibc-2.31
	help2man
	libffi
	misc
	perl5
	pkgconfig
	portage
	python-exec
	python3.7
	systemd
	terminfo
	tmpfiles.d
	xml2Conf.sh

orphan dirs/files (not owned by any package) that will be kept in /home/user/gentoo/usr/lib64/:
	libBrokenLocale.a
	libBrokenLocale.so
	libacl.so
	libacl.so.1
	libacl.so.1.1.2253
	libanl.a
	libanl.so
	libasprintf.so
	libasprintf.so.0
	libasprintf.so.0.0.0
	libassuan.so
	libassuan.so.0
	libassuan.so.0.8.3
	libattr.so
	libattr.so.1
	l

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

2020-11-09 Thread Alexey Sokolov
07.11.2020 12:56, Fabian Groffen пишет:
> On 07-11-2020 11:42:44 +0000, Alexey Sokolov wrote:
>> 22.10.2020 20:16, Andreas K. Hüttel пишет:
>>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>>>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
>>>>> Users frequently are choosing the wrong profile versions in new installs
>>>>> and accidentally downgrading to 17.0 with some saying they see it first.
>>>>>
>>>>> A simple reordering could help new installs.
>>>
>>> Independent of this useful change, it's probably time to deprecate the 
>>> amd64 
>>> 17.0 profiles!
>>>
>>
>> Prefix bootstrap script still makes new installations to use it
> 
> This should be solved with
> 
> b0445c0a8dd6d2f792c5bb088b154aca53868353
> a9c478dc881ee18fefc7342da994b00e60eaad8e
> 
> on gentoo.git and
> 
> 0d7f6b6eb00d0f51f35019846b8f79048b30be93
> 
> on prefix.git.
> 
> Thanks,
> Fabian
> 
> 

Hi Fabian
I tried to migrate my prefix to 17.1, and there are issues.

1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an
error "/usr/lib is a real directory! was the migration done already?"

2) $ unsymlink-lib --root ~/gentoo --migrate --pretend
usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate]
 [--rollback] [--finish] [--force-rollback]
 [--resume-finish] [-P PREFIX] [--hardlink]
unsymlink-lib: error: Requested action requires root privileges

Well, I worked it around by adding "is_root = True" to unsymlink-lib

3) Step 9 (Rebuild gcc) fails:
configure:4372: checking whether the C compiler works



configure:4394: x86_64-pc-linux-gnu-gccconftest.c  >&5



/home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as:
error while loading shared libraries:
libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared
object file: No such file or directory
configure:4398: $? = 1



configure:4436: result: no

The file exists:
$ find ~ -name libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so
/home/user/gentoo/usr/lib/binutils/x86_64-pc-linux-gnu/2.34/libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so

-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

2020-11-07 Thread Alexey Sokolov
07.11.2020 14:39, Andreas K. Huettel пишет:
> 
> 
> On November 7, 2020 1:42:44 PM GMT+02:00, Alexey Sokolov 
>  wrote:
>> 22.10.2020 20:16, Andreas K. Hüttel пишет:
>>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>>>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
>>>>> Users frequently are choosing the wrong profile versions in new
>> installs
>>>>> and accidentally downgrading to 17.0 with some saying they see it
>> first.
>>>>>
>>>>> A simple reordering could help new installs.
>>>
>>> Independent of this useful change, it's probably time to deprecate
>> the amd64 
>>> 17.0 profiles!
>>>
>>
>> Prefix bootstrap script still makes new installations to use it
> 
> Meh. Time to change that then...
> 

Nah, Fabian has just fixed it (in another reply to my message in this
thread)

-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

2020-11-07 Thread Alexey Sokolov
22.10.2020 20:16, Andreas K. Hüttel пишет:
> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
>>> Users frequently are choosing the wrong profile versions in new installs
>>> and accidentally downgrading to 17.0 with some saying they see it first.
>>>
>>> A simple reordering could help new installs.
> 
> Independent of this useful change, it's probably time to deprecate the amd64 
> 17.0 profiles!
> 

Prefix bootstrap script still makes new installations to use it

-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

2020-11-04 Thread Alexey Sokolov
04.11.2020 19:10, Marty E. Plummer пишет:
> On Tue, Nov 03, 2020 at 07:13:32AM +0200, Joonas Niilola wrote:
>> Hey,
>>
> <-snip->
> Just my 2c, One of the major reasons I use gentoo is the ability to use
> live ebuilds relatively easily. One has the equivalent in arch linux in
> the form of ${pkgname}-${vcs} aur packages but keeping them up to date
> is quite annoying.
>>
>> -- juippis
>>
> 

What you're describing is live ebuilds, and I agree they are useful.
Joonas was talking about packages which have *only* live ebuilds, and no
other versions, and not even snapshots.

-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init

2020-10-17 Thread Alexey Sokolov
> > What happens if I ignore this news item and do nothing?
> >
>
> If you ignore this news item and upgrade your packages without installing
> display-manager-init, you will no longer have an 'xdm' init script and you 
> will
> not get a gui on boot.
>

Then please state that clearly in the text. Now it looks like a
request to test some new feature, with no particular benefit for the
user. Especially as it does say "test"



Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init

2020-10-17 Thread Alexey Sokolov
сб, 17 окт. 2020 г. в 23:05, Aisha Tammy :
>
> Hi,
>   I'm attaching the news item for the upcoming display-manager-init changes
>
> Thanks,
> Aisha
>
> ---
>
> Title: New OpenRC Display Manager Initializer Scripts
> Author: Aisha Tammy 
> Posted: 2020-10-17
> Revision: 1
> News-Item-Format: 2.0

This will be shown even if no xdm was installed?

>
> There has been a refactoring of the old 'xdm' init script and its
> requirements from various packages into an independent package:
>
> gui-libs/display-manager-init
>
> This package provides the 'display-manager' startup script for
> handling your chosen display manager, without being dependent on
> Xorg server.
>
> To update to the new DM init scripts, you need to manually add the
> package in your @world set:
>
> emerge -vuDU gui-libs/display-manager-init
>
> To start using the new init scripts, change the DISPLAYMANAGER
> variable in the /etc/conf.d/display-manager to your preferred DM:
>
> DISPLAYMANAGER="gdm"
>
> To test the newly installed scripts, you can try to switch to
> 'display-manager' on the running computer.
> Run the following commands in a tty to test your current install:
>
> rc-service xdm stop
> rc-service display-manager start
>
> If the test succeeds, you can remove the old xdm startup script
> and add display-manager to the default runlevel:
>
> rc-update del xdm default
> rc-update add display-manager default
>
> Reboot your computer to perform a final test and check to see
> that your chosen display manager has started.

What happens if I ignore this news item and do nothing?



Re: [gentoo-dev] [PATCH 5/5] dev-python/miniupnpc: Use verify-sig.eclass

2020-10-06 Thread Alexey Sokolov
вт, 6 окт. 2020 г. в 10:59, Michał Górny :
>
> Signed-off-by: Michał Górny 
> ---
>  dev-python/miniupnpc/Manifest  |  1 +
>  dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild | 11 +++
>  2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/dev-python/miniupnpc/Manifest b/dev-python/miniupnpc/Manifest
> index 955881a8af5a..5341c95b6ff0 100644
> --- a/dev-python/miniupnpc/Manifest
> +++ b/dev-python/miniupnpc/Manifest
> @@ -1 +1,2 @@
>  DIST miniupnpc-2.1.20191224.tar.gz 94740 BLAKE2B 
> 85c0b3eb678685bc7192dbee9440ec5f5be80cbac4d6a4e0a6473662c66f05ef512322cd535a142ffe16d3099a86f78ea70645a7eb2979c373e7a486aeab0cd5
>  SHA512 
> d362f914ce9177c1bc46f1f3ae59069c61c0c9c1b6ea7e78003d6b46445d3550835ffc541c2649b5fbc997d035357b461148edb3648135f33d0ce98b54961917
> +DIST miniupnpc-2.1.20191224.tar.gz.sig 543 BLAKE2B 
> ddbde04faa7bce62fdbb5b555bda9dc9ff69f09cc97442049adc787a03ec91824f14cdddaef6e577cf8d08fa96202fc792333b8dab7e6e8c30847fa9302a35d0
>  SHA512 
> b8885d2002259c95ede7ab57aaf82db83c2bd7ace3d0986179efac4245ffd42161049e0167a9ac1ff18de6c8df4d39356f0fb6aa6dada7523a238b4db4838887
> diff --git a/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild 
> b/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> index 5e1d489b2e1e..e42aadd90e0d 100644
> --- a/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> +++ b/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> @@ -5,11 +5,12 @@ EAPI=7
>
>  PYTHON_COMPAT=( python3_{6,7,8} pypy3 )
>
> -inherit distutils-r1
> +inherit distutils-r1 verify-sig
>
>  DESCRIPTION="Python bindings for UPnP client library"
>  HOMEPAGE="http://miniupnp.free.fr/;
> -SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz;
> +SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz
> +   verify-sig? ( http://miniupnp.free.fr/files/${P}.tar.gz.sig )"
>
>  LICENSE="BSD"
>  SLOT="0"
> @@ -17,8 +18,10 @@ KEYWORDS="amd64 ppc ppc64 x86"
>  IUSE=""
>
>  RDEPEND=">=net-libs/miniupnpc-${PV}:0="
> -DEPEND="${RDEPEND}
> -   dev-python/setuptools[${PYTHON_USEDEP}]"
> +DEPEND="${RDEPEND}"
> +BDEPEND="verify-sig? ( app-crypt/openpgp-keys-miniupnp )"
> +
> +VERIFY_SIG_OPENPGP_KEY_PATH=/usr/share/openpgp-keys/miniupnp.asc

Shouldn't this be prefixed with ${BROOT}? (preferably, in the eclass)

>
>  PATCHES=(
> "${FILESDIR}"/miniupnpc-2.0.20171102-shared-lib.patch
> --
> 2.28.0
>
>



Re: [gentoo-dev] Please port your packages to Python 3.8

2020-09-01 Thread Alexey Sokolov
вт, 1 сент. 2020 г. в 13:06, Rich Freeman :
>
> On Tue, Sep 1, 2020 at 7:02 AM Michał Górny  wrote:
> >
> > QA reports provide a list [2] and a graph [3] of packages needing
> > porting.
>
> These lists would be far more useful if they actually listed the
> maintainer(s) of each package.  Then devs could just grep to discover
> if any of their packages need fixing.
>
> Otherwise I fear that you're just going to run into the same issue as
> last time - most devs will just wait until you take the time to do
> this and file bugs.
>

I would also like a warning shown in p.g.o if the package is in one of
these qa lists



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

2020-08-29 Thread Alexey Sokolov
As this doesn't depend on architecture, why /lib and not /share?

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



Re: [gentoo-dev] RFC: packages.g.o: new features available

2020-07-08 Thread Alexey Sokolov
It's great, thanks!

I was confused at first at two different buttons "Pull requests", one
showing them inline, one going to github, and two different buttons
"Bugs", one showing them inline, one going to bugzilla.

Sources of data seem to be inconsistent:
https://i.imgur.com/PM138E2.png Well, to be fair, the new ebuild was
just pushed.

Another comment, unrelated to the new features: RESTRICT="test?
(test)" probably shouldn't trigger the T symbol the same way as
RESTRICT="test" does.

ср, 8 июл. 2020 г. в 03:58, Max Magorsch :
>
> Hi all,
>
> I am glad to announce further progress at packages.gentoo.org (pgo in
> the following). Compared to previous work during the last months,
> which mostly addressed the back end, the new changes are rather
> comprehensive. That's why I am looking forward to feedback here.
>
> So the tl;dr is that the new pgo version now displays:
>   - dependencies
>   - reverse dependencies
>   - pkgcheck results
>   - repology.org data
>   - github pull requests
>   - stabilization bugs
>   - keywording bugs
>   - security bugs
>   - general bugs
> for each package.
>
> Additionally, there are new sites for all package maintainers, that is:
>   - Gentoo Projects (e.g. pyt...@gentoo.org)
>   - Gentoo Developers  (e.g. la...@gentoo.org
>   - Proxied Maintainers (e.g. la...@the-cow.de)
>
> The maintainer's sites contain:
>   - all packages of the maintainer
>   - all outdated packages (according to repology)
>   - all related pull requests
>   - all related bugs (general, keywording and stabilization)
>   - all security bugs
>   - the changelog of all maintained packages
> You will find the new sites under the 'Maintainers' tab.
>
> The overall appearance of the site has also slightly changed to
> display all of the new information.
>
> Currently, the new version is deployed to:
>
>   https://packagestest.gentoo.org/
>
> Everyone is welcome to take a look around and tell me whether you
> consider the new information as useful for your workflow and/or what
> you would still change.
>
> I'm looking forward to your feedback.
>
> -M
>



Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

2020-06-07 Thread Alexey Sokolov
вс, 7 июн. 2020 г. в 09:10, Pacho Ramos :
>
>
> I think this is the list of completely unmaintained packages now (indeed most 
> of
> them, around 100) :)
>
> x11-misc/shutter

I'm updating this one right now



Re: [gentoo-dev] Package up for grabs: dev-cpp/asio

2020-06-02 Thread Alexey Sokolov
вт, 2 июн. 2020 г. в 02:27, Stefan Strogin :
>
> Hi,
>
> I don't use dev-cpp/asio or any of its reverse dependencies any longer.
>
> CC to mysql-bugs, because sys-cluster/galera depends on dev-cpp/asio.
>

Hi. I can take it unless someone else wants to.