Re: [gentoo-dev] Package up for grabs: app-arch/snappy
Well, with a little patch magic, I was able to make GTest suite as an optional dependency. Here PR: https://github.com/gentoo/gentoo/pull/20692 ср, 5 мая 2021 г. в 21:09, Michał Górny : > On Wed, 2021-05-05 at 19:47 +0300, Azamat Hackimov wrote: > > Strangely enough, upstream actually released new 1.1.9 a few hours ago. I > > don't see any issues with git submodules (there only gtest and benchmark > > libraries which can be disabled via cmake). > > Anyway, I can take maintainership over it. > > > > Disabling the tests is not a solution. > > -- > Best regards, > Michał Górny > > > > -- >From Siberia with Love!
Re: [gentoo-dev] [PATCH news v3] Add Python 3.9 news item
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 + +Наконец, вот окончательная версия, и не забудьте запустить команды: + +*/* PYTHON_TARGETS: -* python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_9 + +После смены
[gentoo-dev] Package up for grabs: app-arch/snappy
Hi, The following package needs a new maintainer: app-arch/snappy Technically, it's not a high traffic package. It's pending version bump but upstream did not bother providing a working release archive, and GitHub archives do not work because they are missing git submodules. That said, it's a typical Google open source package -- bad quality, doesn't care the slightest bit about accepting patches or getting bug reports, or even making working releases. -- Best regards, Michał Górny
[gentoo-dev] last-rite: some java packages
# Miroslav Šulc (2021-05-05) # no consumers, dead homepage # removal in 30 days # see bug: https://bugs.gentoo.org/787329 app-misc/jitac # Miroslav Šulc (2021-05-05) # last release in 2009 # removal in 30 days # see bug: https://bugs.gentoo.org/787332 app-office/hourglass # Miroslav Šulc (2021-05-05) # no consumers, last release in 2005 # removal in 30 days # see bug: https://bugs.gentoo.org/787368 dev-util/jarwizard # Miroslav Šulc (2021-05-05) # no consumers, last release in 2008 # removal in 30 days # see bug: https://bugs.gentoo.org/787428 media-sound/entagged-tageditor # Miroslav Šulc (2021-05-05) # no consumers, last release in 2009 # removal in 30 days # see bug: https://bugs.gentoo.org/787434 media-sound/protux # Miroslav Šulc (2021-05-05) # no consumers, last release in 2013 # removal in 30 days # see bug: https://bugs.gentoo.org/787638 net-nds/jxplorer # Miroslav Šulc (2021-05-05) # no consumers, last release in 2011 # removal in 30 days # see bug: https://bugs.gentoo.org/787656 sci-physics/jaxodraw # Miroslav Šulc (2021-05-05) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/785400 dev-java/cldc-api
Re: [gentoo-dev] Package up for grabs: app-arch/snappy
Strangely enough, upstream actually released new 1.1.9 a few hours ago. I don't see any issues with git submodules (there only gtest and benchmark libraries which can be disabled via cmake). Anyway, I can take maintainership over it. ср, 5 мая 2021 г. в 12:54, Michał Górny : > Hi, > > The following package needs a new maintainer: > > app-arch/snappy > > Technically, it's not a high traffic package. It's pending version bump > but upstream did not bother providing a working release archive, > and GitHub archives do not work because they are missing git submodules. > > That said, it's a typical Google open source package -- bad quality, > doesn't care the slightest bit about accepting patches or getting bug > reports, or even making working releases. > > -- > Best regards, > Michał Górny > > > > -- >From Siberia with Love!
[gentoo-portage-dev] KeyError: 'ED' ?
I am upgrading an old portage(2.3.76) to 3.0.18 using qmerge(binary pkg) and I get this: qmerge -OK sys-apps/portage [R] sys-apps/portage-3.0.18 * Checking for suitable kernel configuration options... [ ok ] * Using python3.8 in global scope FEATURES variable contains unknown value(s): disabled Traceback (most recent call last): File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/lib/python3.8/runpy.py", line 87, in _run_code exec(code, run_globals) File "/var/tmp/qmerge/sys-apps/portage-3.0.18/image/usr/lib/python3.8/site-packages/portage/_compat_upgrade/default_locations.py", line 93, in main() File "/var/tmp/qmerge/sys-apps/portage-3.0.18/image/usr/lib/python3.8/site-packages/portage/_compat_upgrade/default_locations.py", line 63, in main config_path = os.path.join(os.environ['ED'], GLOBAL_CONFIG_PATH.lstrip(os.sep), 'make.globals') File "/usr/lib/python3.8/os.py", line 675, in __getitem__ raise KeyError(key) from None KeyError: 'ED' so portage fails to install properly, I am guessin this is becuse I have an old portage to begin with? Can it be fixed? Also, these "FEATURES variable contains unknown value(s): disabled" could tell me which value it does not like. Jocke
[gentoo-dev] [PATCH] python-utils-r1.eclass: Grab paths from sysconfig module
Grab site-packages and includedir paths from sysconfig rather than
distutils.sysconfig, as the latter module is deprecated. The new method
results in the same paths for all supported implementations,
as confirmed by the tests.
Signed-off-by: Michał Górny
---
eclass/python-utils-r1.eclass | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 60526b1f6b14..0082a231f0a0 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -318,16 +318,13 @@ _python_export() {
;;
PYTHON_SITEDIR)
[[ -n ${PYTHON} ]] || die "PYTHON needs to be
set for ${var} to be exported, or requested before it"
- # sysconfig can't be used because:
- # 1) pypy doesn't give site-packages but stdlib
- # 2) jython gives paths with wrong case
- PYTHON_SITEDIR=$("${PYTHON}" -c 'import
distutils.sysconfig; print(distutils.sysconfig.get_python_lib())') || die
+ PYTHON_SITEDIR=$("${PYTHON}" -c 'import
sysconfig; print(sysconfig.get_path("purelib"))') || die
export PYTHON_SITEDIR
debug-print "${FUNCNAME}: PYTHON_SITEDIR =
${PYTHON_SITEDIR}"
;;
PYTHON_INCLUDEDIR)
[[ -n ${PYTHON} ]] || die "PYTHON needs to be
set for ${var} to be exported, or requested before it"
- PYTHON_INCLUDEDIR=$("${PYTHON}" -c 'import
distutils.sysconfig; print(distutils.sysconfig.get_python_inc())') || die
+ PYTHON_INCLUDEDIR=$("${PYTHON}" -c 'import
sysconfig; print(sysconfig.get_path("platinclude"))') || die
export PYTHON_INCLUDEDIR
debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
${PYTHON_INCLUDEDIR}"
--
2.31.1
Re: [gentoo-dev] Package up for grabs: app-arch/snappy
On Wed, 2021-05-05 at 19:47 +0300, Azamat Hackimov wrote: > Strangely enough, upstream actually released new 1.1.9 a few hours ago. I > don't see any issues with git submodules (there only gtest and benchmark > libraries which can be disabled via cmake). > Anyway, I can take maintainership over it. > Disabling the tests is not a solution. -- Best regards, Michał Górny
