[devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 10063 bytes --]

На самом деле, если собирать через gear --hasher -- hsh, то для этих 
пакетов (на которые я повлиял -- 
https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-July/103961.html 
) всё успешно.

Например, для rpm: 

(Правда, для rpm я эти добавки в сборочную среду отключу, патч сейчас 
пришлю -- ради бутстрапа и вообще, а другим питоновским пакетам эти 
добавки не помешают, кроме setuptools, где я уже отключил):

Building target platforms: x86_64
Building for target x86_64
Wrote: /usr/src/in/srpm/rpm-4.13.0.1-alt2.src.rpm
<13>Jul  3 07:04:28 rpmi: python3-module-pkg_resources-1:39.2.0-alt5.S1 
1530501248 installed
<13>Jul  3 07:04:28 rpmi: python-tools-2to3-2.7.14-alt7 1530486275 
installed
<13>Jul  3 07:04:28 rpmi: python-module-pkg_resources-1:39.2.0-alt5.S1 
1530501248 installed
<13>Jul  3 07:04:28 rpmi: python-module-setuptools-1:39.2.0-alt5.S1 
1530501248 installed
<13>Jul  3 07:04:28 rpmi: python3-module-setuptools-1:39.2.0-alt5.S1 
1530501248 installed
Installing rpm-4.13.0.1-alt2.src.rpm
Building target platforms: x86_64
Building for target x86_64
Executing(%prep): /bin/sh -e /usr/src/tmp/rpm-tmp.21110


Или пробую -- тоже успешно:

$ hsh --apt-config=/home/imz/.hasher/sisyphus/apt.conf 
--without-stuff --query-repackage 
/ALT/Sisyphus/files/SRPMS/rpm-4.13.0.1-alt2.src.rpm 
...
<13>Jul  3 07:14:41 rpmi: python-module-setuptools-1:39.2.0-alt5.S1 
1530501248 installed
<13>Jul  3 07:14:41 rpmi: python3-module-setuptools-1:39.2.0-alt5.S1 
1530501248 installed
....
Installing rpm-4.13.0.1-alt2.src.rpm
Building target platforms: x86_64
Building for target x86_64
Executing(%prep): /bin/sh -e /usr/src/tmp/rpm-tmp.61500
...

Нельзя при тестовой пересборке так делать, чтобы получить результаты ближе 
к тому, с чем столкнётся мейнтейнер, пытаясь собрать очередной релиз 
пакета? (Также можно это учесть в скриптах пересборки для сертификации.)

Хотя в моих вчерашних экспериментах --query-repackage не всегда помогал 
(если я правильно помню), но подробности не могу вспомнить, к тому же мне 
это показалось странным.

On Tue, 3 Jul 2018, ALT beekeeper wrote:

> Package: rpm-4.13.0.1-alt2
> Status: Sisyphus/x86_64 test rebuild failed
> Cannot build this package.
> Please investigate.
> Excerpt from build log:
> 
> <86>Jul  3 02:29:23 userdel[115421]: delete user 'rooter'
> <86>Jul  3 02:29:23 userdel[115421]: removed group 'rooter' owned by 'rooter'
> <86>Jul  3 02:29:23 userdel[115421]: removed shadow group 'rooter' owned by 'rooter'
> <86>Jul  3 02:29:23 groupadd[115428]: group added to /etc/group: name=rooter, GID=528
> <86>Jul  3 02:29:23 groupadd[115428]: group added to /etc/gshadow: name=rooter
> <86>Jul  3 02:29:23 groupadd[115428]: new group: name=rooter, GID=528
> <86>Jul  3 02:29:23 useradd[115433]: new user: name=rooter, UID=528, GID=528, home=/root, shell=/bin/bash
> <86>Jul  3 02:29:23 userdel[115444]: delete user 'builder'
> <86>Jul  3 02:29:23 userdel[115444]: removed group 'builder' owned by 'builder'
> <86>Jul  3 02:29:23 userdel[115444]: removed shadow group 'builder' owned by 'builder'
> <86>Jul  3 02:29:23 groupadd[115453]: group added to /etc/group: name=builder, GID=529
> <86>Jul  3 02:29:23 groupadd[115453]: group added to /etc/gshadow: name=builder
> <86>Jul  3 02:29:23 groupadd[115453]: new group: name=builder, GID=529
> <86>Jul  3 02:29:23 useradd[115462]: new user: name=builder, UID=529, GID=529, home=/usr/src, shell=/bin/bash
> <13>Jul  3 02:29:28 rpmi: libexpat-2.2.4-alt1 1503305341 installed
> <13>Jul  3 02:29:28 rpmi: libgdbm-1.8.3-alt10 1454943313 installed
> <13>Jul  3 02:29:28 rpmi: autoconf_2.50-2:2.59-alt11 1449525230 installed
> <13>Jul  3 02:29:28 rpmi: libmemcached-1.0.18-alt2 1527933590 installed
> <13>Jul  3 02:29:28 rpmi: liblzo2-2.08-alt1 1405435908 installed
> <13>Jul  3 02:29:28 rpmi: lua5.3-5.3.4-alt2 1505285816 installed
> <13>Jul  3 02:29:28 rpmi: liblz4-1:1.8.1.2-alt1 1520474473 installed
> <13>Jul  3 02:29:28 rpmi: libgpg-error-1.31-alt1.S1 1529015796 installed
> <13>Jul  3 02:29:28 rpmi: libgcrypt20-1.7.10-alt1.S1 1529015978 installed
> <13>Jul  3 02:29:28 rpmi: libsystemd-1:238-alt8 1526495096 installed
> <13>Jul  3 02:29:28 rpmi: libdbus-1.10.24-alt4.S1 1518772734 installed
> <13>Jul  3 02:29:28 rpmi: libnettle6-3.4-alt1 1511790158 installed
> <13>Jul  3 02:29:28 rpmi: libarchive13-3.3.1-alt1.S1 1488799499 installed
> <13>Jul  3 02:29:28 rpmi: libelf-devel-0.173-alt1 1530382462 installed
> <13>Jul  3 02:29:28 rpmi: libdw-devel-0.173-alt1 1530382462 installed
> <13>Jul  3 02:29:28 rpmi: libasm-devel-0.173-alt1 1530382462 installed
> <13>Jul  3 02:29:29 rpmi: glibc-devel-static-6:2.27-alt6 1530125885 installed
> <13>Jul  3 02:29:29 rpmi: zlib-devel-1.2.8-alt1 1371079009 installed
> <13>Jul  3 02:29:29 rpmi: zlib-devel-static-1.2.8-alt1 1371079009 installed
> <13>Jul  3 02:29:29 rpmi: libtinfo-devel-6.1.20180407-alt1 1524068795 installed
> <13>Jul  3 02:29:29 rpmi: libncurses-devel-6.1.20180407-alt1 1524068795 installed
> <13>Jul  3 02:29:29 rpmi: python-modules-curses-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:29 rpmi: libverto-0.3.0-alt1_5 1525957716 installed
> <13>Jul  3 02:29:29 rpmi: libkeyutils-1.5.10-alt1 1489994069 installed
> <13>Jul  3 02:29:29 rpmi: libcom_err-1.44.2-alt1 1528233217 installed
> <13>Jul  3 02:29:29 rpmi: libtasn1-4.13-alt2 1521133848 installed
> <13>Jul  3 02:29:29 rpmi: libp11-kit-0.23.9-alt5 1525798241 installed
> <13>Jul  3 02:29:29 rpmi: ca-certificates-2017.11.22-alt3 1515521666 installed
> <13>Jul  3 02:29:29 rpmi: ca-trust-0.1.1-alt2 1515595785 installed
> <13>Jul  3 02:29:29 rpmi: p11-kit-trust-0.23.9-alt5 1525798241 installed
> <13>Jul  3 02:29:30 rpmi: libcrypto10-1.0.2o-alt1 1522836697 installed
> <86>Jul  3 02:29:30 groupadd[129372]: group added to /etc/group: name=_keytab, GID=499
> <86>Jul  3 02:29:30 groupadd[129372]: group added to /etc/gshadow: name=_keytab
> <86>Jul  3 02:29:30 groupadd[129372]: new group: name=_keytab, GID=499
> <13>Jul  3 02:29:30 rpmi: libkrb5-1.16-alt1.S1 1516715375 installed
> <13>Jul  3 02:29:30 rpmi: libssl10-1.0.2o-alt1 1522836697 installed
> <13>Jul  3 02:29:30 rpmi: rpm-build-python3-0.1.13-alt1 1530500929 installed
> <13>Jul  3 02:29:30 rpmi: python3-3.6.5-alt1 1528894178 installed
> <13>Jul  3 02:29:30 rpmi: python3-base-3.6.5-alt1 1528894178 installed
> <13>Jul  3 02:29:30 rpmi: libpython3-3.6.5-alt1 1528894178 installed
> <13>Jul  3 02:29:30 rpmi: libtirpc-1.0.2-alt2 1516108441 installed
> <13>Jul  3 02:29:30 rpmi: libnsl2-1.1.0-alt1_1 1511548748 installed
> <13>Jul  3 02:29:30 rpmi: python-modules-compiler-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:30 rpmi: python-modules-email-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:30 rpmi: python-modules-unittest-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:30 rpmi: python-modules-nis-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:30 rpmi: python-modules-encodings-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:31 rpmi: python-modules-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:31 rpmi: python-modules-xml-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:31 rpmi: python-modules-hotshot-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:31 rpmi: python-modules-bsddb-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:31 rpmi: python-modules-ctypes-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:31 rpmi: python-modules-multiprocessing-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:31 rpmi: python-modules-logging-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:31 rpmi: python-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:31 rpmi: python-modules-distutils-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:31 rpmi: libnsl2-devel-1.1.0-alt1_1 1511548748 installed
> <13>Jul  3 02:29:31 rpmi: python-dev-2.7.14-alt7 1530486275 installed
> <13>Jul  3 02:29:31 rpmi: python3-dev-3.6.5-alt1 1528894178 installed
> <13>Jul  3 02:29:31 rpmi: binutils-devel-1:2.30.0-alt1 1527783179 installed
> <13>Jul  3 02:29:31 rpmi: elfutils-devel-0.173-alt1 1530382462 installed
> <13>Jul  3 02:29:31 rpmi: libarchive-devel-3.3.1-alt1.S1 1488799499 installed
> <13>Jul  3 02:29:31 rpmi: libdbus-devel-1.10.24-alt4.S1 1518772734 installed
> <13>Jul  3 02:29:31 rpmi: liblua5.3-devel-5.3.4-alt2 1505285816 installed
> <13>Jul  3 02:29:31 rpmi: liblzo2-devel-2.08-alt1 1405435908 installed
> <13>Jul  3 02:29:31 rpmi: libmemcached-devel-1.0.18-alt2 1527933590 installed
> <13>Jul  3 02:29:31 rpmi: automake_1.9-1:1.9.6-alt6 1449516872 installed
> <13>Jul  3 02:29:32 rpmi: libreadline-devel-7.0.3-alt2 1526988921 installed
> <13>Jul  3 02:29:32 rpmi: bzlib-devel-1:1.0.6-alt5 1508883138 installed
> <13>Jul  3 02:29:32 rpmi: libselinux-devel-1:2.7-alt1 1527510798 installed
> <13>Jul  3 02:29:32 rpmi: libpopt-devel-1:1.16-alt1 1500322984 installed
> <13>Jul  3 02:29:32 rpmi: libmagic-devel-4.26-alt13 1490157134 installed
> <13>Jul  3 02:29:32 rpmi: liblzma-devel-5.2.3-alt2 1517075184 installed
> <13>Jul  3 02:29:32 rpmi: libdb4.7-devel-4.7.25-alt9 1490438456 installed
> <13>Jul  3 02:29:32 rpmi: libcap-devel-1:2.25-alt1 1490633683 installed
> <13>Jul  3 02:29:32 rpmi: libbeecrypt-devel-4.2.1-alt7 1302194536 installed
> <13>Jul  3 02:29:32 rpmi: libacl-devel-2.2.52.0.52.33f0-alt2 1511850751 installed
> <13>Jul  3 02:29:32 rpmi: fakechroot-2.19-alt1 1487767618 installed
> error: failed build dependencies:
> 	python-module-setuptools   is needed by rpm-4.13.0.1-alt2
> 	python3-module-setuptools   is needed by rpm-4.13.0.1-alt2
> Installing rpm-4.13.0.1-alt2.src.rpm
> Building target platforms: x86_64
> Building for target x86_64
> Command exited with non-zero status 1
> 0.40user 0.02system 0:00.80elapsed 53%CPU (0avgtext+0avgdata 12768maxresident)k
> 0inputs+0outputs (0major+7240minor)pagefaults 0swaps
> hsh-rebuild: rebuild of `rpm-4.13.0.1-alt2.src.rpm' failed.
> Command exited with non-zero status 1
> 12.95user 2.23system 0:18.80elapsed 80%CPU (0avgtext+0avgdata 127352maxresident)k
> 680inputs+0outputs (0major+414780minor)pagefaults 0swaps
> 
> -- 
> Sincerely yours,
> ALT beekeeper
> 

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

On Tue, Jul 03, 2018 at 10:21:51AM +0300, Ivan Zakharyaschev wrote:
> На самом деле, если собирать через gear --hasher -- hsh, то для этих 
> пакетов (на которые я повлиял -- 
> https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-July/103961.html 
> ) всё успешно.
> 
> Например, для rpm: 
> 
> (Правда, для rpm я эти добавки в сборочную среду отключу, патч сейчас 
> пришлю -- ради бутстрапа и вообще, а другим питоновским пакетам эти 
> добавки не помешают, кроме setuptools, где я уже отключил):
> 
> Building target platforms: x86_64
> Building for target x86_64
> Wrote: /usr/src/in/srpm/rpm-4.13.0.1-alt2.src.rpm
> <13>Jul  3 07:04:28 rpmi: python3-module-pkg_resources-1:39.2.0-alt5.S1 
> 1530501248 installed
> <13>Jul  3 07:04:28 rpmi: python-tools-2to3-2.7.14-alt7 1530486275 
> installed
> <13>Jul  3 07:04:28 rpmi: python-module-pkg_resources-1:39.2.0-alt5.S1 
> 1530501248 installed
> <13>Jul  3 07:04:28 rpmi: python-module-setuptools-1:39.2.0-alt5.S1 
> 1530501248 installed
> <13>Jul  3 07:04:28 rpmi: python3-module-setuptools-1:39.2.0-alt5.S1 
> 1530501248 installed
> Installing rpm-4.13.0.1-alt2.src.rpm
> Building target platforms: x86_64
> Building for target x86_64
> Executing(%prep): /bin/sh -e /usr/src/tmp/rpm-tmp.21110
> 
> Или пробую -- тоже успешно:
> 
> $ hsh --apt-config=/home/imz/.hasher/sisyphus/apt.conf 
> --without-stuff --query-repackage 
> /ALT/Sisyphus/files/SRPMS/rpm-4.13.0.1-alt2.src.rpm 
> ...
> <13>Jul  3 07:14:41 rpmi: python-module-setuptools-1:39.2.0-alt5.S1 
> 1530501248 installed
> <13>Jul  3 07:14:41 rpmi: python3-module-setuptools-1:39.2.0-alt5.S1 
> 1530501248 installed
> ....
> Installing rpm-4.13.0.1-alt2.src.rpm
> Building target platforms: x86_64
> Building for target x86_64
> Executing(%prep): /bin/sh -e /usr/src/tmp/rpm-tmp.61500
> ...
> 
> Нельзя при тестовой пересборке так делать, чтобы получить результаты ближе 
> к тому, с чем столкнётся мейнтейнер, пытаясь собрать очередной релиз 
> пакета? (Также можно это учесть в скриптах пересборки для сертификации.)
> 
> Хотя в моих вчерашних экспериментах --query-repackage не всегда помогал 
> (если я правильно помню), но подробности не могу вспомнить, к тому же мне 
> это показалось странным.

Так не годится.  В нынешнем виде тестовая пересборка утратила смысл.
Если эти изменения вообще были нужны (в чём я сильно сомневаюсь),
то следовало сперва адаптировать измерительный инструмент.

А теперь чините сами, мне сейчас некогда вникать в эту тему.
Я оставляю за собой право откатить все изменения, если не будет
продемонстрирована их правильность (пока не продемонстрирована).


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

Вот такое предложение по изменению в beehive (см. патч), чтобы приблизить 
измерение к ситуации, когда мейнтейнер хочет собрать релиз пакета, потому 
что надо исправить ошибку.

Если такое изменение можно внести, хотел бы попросить ещё разок запустить 
пересборку.

-- 
Best regards,
Ivan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch; name=0001-use-hsh-query-repackage-to-simulate-a-maintainer-mak.patch, Size: 1262 bytes --]

From 90877c1c9f0981885b1046fe8b9abcce5298d206 Mon Sep 17 00:00:00 2001
From: Ivan Zakharyaschev <imz@altlinux.org>
Date: Tue, 3 Jul 2018 12:02:17 +0300
Subject: [PATCH] use hsh --query-repackage (to simulate a maintainer making a
 new release)

Whenever a maintainer of a package wants to make a new release of the
package (perhaps, to fix a bug), he does repackage the srpm anyway.

So, whether a plain "hsh" fails is not the best indication that the
maintainer won't be able to build a new release of a package (when he
needs to). "hsh --query-repackage" is a better measurement because it
will give less false warnings. And whenever "hsh --query-repackage"
worked susccessfully, the maintainer would succeed, too.

--query-repackage was introduced in hasher-1.0.15-alt1 on May 17 2005.
---
 remote/nectar | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/remote/nectar b/remote/nectar
index 62d0c6e..cd9d5c7 100755
--- a/remote/nectar
+++ b/remote/nectar
@@ -9,7 +9,7 @@ workdir="$TMPDIR/hasher"
 
 rm -rf -- "$workdir/repo"
 
-time hsh -- "$workdir" "$file" </dev/null ||
+time hsh --query-repackage -- "$workdir" "$file" </dev/null ||
 	exit 7
 
 # compare hasher packages and repo packages
-- 
2.10.4

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]


1. Обоснование последнего изменения (в rpm-build-python*): облегчить 
написание стандартных спеков для питон-пакетов для мейнтейнеров.

Не нужно дописывать в BuildRequires/BuildPreReq то, что и так в 
большинстве случаев нужно написать, а именно стандартный инструмент, 
"интерпретирующий" setup.py -- python*-module-setuptools.

Подробности: Если используются макросы %python_build/install (обращающиеся 
к setup.py), то с большой вероятностью используются setuptools. (Вреда от 
их наличия не будет.)

2. Обоснование изменений в python-dev и python*-module-setuptools: просто 
распилить на части, которые в разных ситуациях полезны (runtime vs 
development). 

То, что что-то сломавшееся раньше собиралось -- случайное совпадение. Были 
недостаточные BuildRequires, и только благодаря транзитивным зависимостям 
некоторых инструментов оно приезжало в сборочныу среду сломавшихся 
пакетов.

* * *

В сочетании 1 и 2 ещё и восстановят пересобираемость большинства 

сломавшихся пакетов (при условии использования hsh --query-repackage; а 
пока 1 помешало пересборке некоторых пакетов).

* * *

Техническая хитрость в 1: эта удобная мейнтейнерам зависмость на 
setuptools добаляется чреез %_buildrequires_build (как в 
%set_gcc_version). Тащить в виде Requires пакета для всех не хочется, 
потому что этот пакет ставится почти всем, а setuptools всем не нужен.

-- 
Best regards,
Ivan

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

On Tue, 3 Jul 2018, Ivan Zakharyaschev wrote:

> 1. Обоснование последнего изменения (в rpm-build-python*): облегчить 
> написание стандартных спеков для питон-пакетов для мейнтейнеров.
> 
> Не нужно дописывать в BuildRequires/BuildPreReq то, что и так в 
> большинстве случаев нужно написать, а именно стандартный инструмент, 
> "интерпретирующий" setup.py -- python*-module-setuptools.

> * * *
> 
> В сочетании 1 и 2 ещё и восстановят пересобираемость большинства 
> 
> сломавшихся пакетов (при условии использования hsh --query-repackage; а 
> пока 1 помешало пересборке некоторых пакетов).

У меня есть план, если изменить поведение beehive не удастся, как убрать 
расстраивающие ошибки из результатов пересборки: просто руками (girar-nmu 
или т.п.) пересобрать значительную часть этих пакетов без изменений (кроме 
Release).

-- 
Best regards,
Ivan

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Dmitry V. Levin]

On Tue, Jul 03, 2018 at 12:08:22PM +0300, Ivan Zakharyaschev wrote:
> Вот такое предложение по изменению в beehive (см. патч), чтобы приблизить 
> измерение к ситуации, когда мейнтейнер хочет собрать релиз пакета, потому 
> что надо исправить ошибку.
> 
> Если такое изменение можно внести, хотел бы попросить ещё разок запустить 
> пересборку.

OK, пересборка была запущена в 10:25 UTC.


-- 
ldv

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Tue, 3 Jul 2018, Ivan Zakharyaschev wrote:

> На самом деле, если собирать через gear --hasher -- hsh, то для этих 
> пакетов (на которые я повлиял -- 
> https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-July/103961.html 
> ) всё успешно.
> 
> Например, для rpm: 
> 
> (Правда, для rpm я эти добавки в сборочную среду отключу, патч сейчас 
> пришлю -- ради бутстрапа и вообще, а другим питоновским пакетам эти 
> добавки не помешают, кроме setuptools, где я уже отключил):

Сделал коммит, который прошу при очередной сборке rpm учесть. (См. патч.)

-- 
Best regards,
Ivan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch; name=0001-.spec-Opt-out-of-the-extra-Python-setuptools-build-r.patch, Size: 856 bytes --]

From b9317a450cc4b7a0195a647147a1c9cde91a855d Mon Sep 17 00:00:00 2001
From: Ivan Zakharyaschev <imz@altlinux.org>
Date: Tue, 3 Jul 2018 13:59:09 +0300
Subject: [PATCH] (.spec) Opt out of the extra Python setuptools build
 requirement

Particularly, this is useful for bootstrap.

This extra build requirement is imposed by recent rpm-build-python*
for the convenience of maintainers of Python packages.
(rpm-build-python-0.37.0-alt1 , rpm-build-python3-0.1.13-alt1)
---
 alt/rpm.spec | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/alt/rpm.spec b/alt/rpm.spec
index 9254623..da6a58b 100644
--- a/alt/rpm.spec
+++ b/alt/rpm.spec
@@ -275,7 +275,9 @@ done;
 %make_build
 
 pushd python
+%define python_setup_buildrequires %nil
 %python_build
+%define python3_setup_buildrequires %nil
 %python3_build
 popd
 
-- 
2.10.4

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Vitaly Lipatov]

Ivan Zakharyaschev писал 3.7.18 12:39:
> 1. Обоснование последнего изменения (в rpm-build-python*): облегчить
> написание стандартных спеков для питон-пакетов для мейнтейнеров.
> 
> Не нужно дописывать в BuildRequires/BuildPreReq то, что и так в
> большинстве случаев нужно написать, а именно стандартный инструмент,
> "интерпретирующий" setup.py -- python*-module-setuptools.
> 
> Подробности: Если используются макросы %python_build/install 
> (обращающиеся
> к setup.py), то с большой вероятностью используются setuptools. (Вреда 
> от
> их наличия не будет.)

Хорошо, что теперь можно не указывать setuptools. Но объясните, почему 
при его указании он не находится:

<13>Jul  3 11:16:17 rpmi: python-modules-distutils-2.7.14-alt7 
1530486275 installed
<13>Jul  3 11:16:17 rpmi: libnsl2-devel-1.1.0-alt1_1 1511548748 
installed
<13>Jul  3 11:16:17 rpmi: python-dev-2.7.14-alt7 1530486275 installed
<13>Jul  3 11:16:17 rpmi: python-module-mysql-2.1.7-alt1 1528642037 
installed
error: failed build dependencies:
	python-module-setuptools   is needed by mysql-utilities-1.6.5-alt1
Installing mysql-utilities-1.6.5-alt1.src.rpm



> 
> 2. Обоснование изменений в python-dev и python*-module-setuptools: 
> просто
> распилить на части, которые в разных ситуациях полезны (runtime vs
> development).

Напомните заодно про использовать python-dev и python-devel, какой и для 
чего нужен.

(Конечно, python-dev — крайне неудачное название, вызывающее ненужные 
ассоциации с dev-пакетами Debian)


-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

On Tue, 3 Jul 2018, Dmitry V. Levin wrote:

> On Tue, Jul 03, 2018 at 12:08:22PM +0300, Ivan Zakharyaschev wrote:
> > Вот такое предложение по изменению в beehive (см. патч), чтобы приблизить 
> > измерение к ситуации, когда мейнтейнер хочет собрать релиз пакета, потому 
> > что надо исправить ошибку.
> > 
> > Если такое изменение можно внести, хотел бы попросить ещё разок запустить 
> > пересборку.
> 
> OK, пересборка была запущена в 10:25 UTC.

Спасибо!

Извините, но результаты плохие, прошу не обращать на них внимание. (Не 
учитывать в статистике, не рассылать письма.)

Причина простая:

Wrote: /usr/src/RPM/RPMS/x86_64/0ad-0.0.23-alt2.x86_64.rpm
Wrote: /usr/src/RPM/RPMS/x86_64/0ad-debuginfo-0.0.23-alt2.x86_64.rpm
2193.03user 128.40system 10:20.07elapsed 374%CPU (0avgtext+0avgdata 
808516maxresident)k
0inputs+0outputs (0major+42888514minor)pagefaults 0swaps
sisyphus_check: check-packager ERROR: packager name violation
/.out/0ad-0.0.23-alt2.src.rpm: wrong PACKAGER: Automated package hasher 
<hasher@localhost>
hsh-rebuild: 0ad-0.0.23-alt2.src.rpm: sisyphus_check failed.
Command exited with non-zero status 1


.src.rpm не проходит sisyphus_check. Я ещё поизучаю код beehive и hasher, 
и попробую предложить работающее изменение для beehive. (Локально этого не 
заметил.)

Пока прошу откатить изменение в beehive.

Извините за беспокойство неудачными изменениями!

-- 
Best regards,
Ivan

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]


On Tue, 3 Jul 2018, Vitaly Lipatov wrote:

> Ivan Zakharyaschev писал 3.7.18 12:39:
> > 1. Обоснование последнего изменения (в rpm-build-python*): облегчить
> > написание стандартных спеков для питон-пакетов для мейнтейнеров.
> > 
> > Не нужно дописывать в BuildRequires/BuildPreReq то, что и так в
> > большинстве случаев нужно написать, а именно стандартный инструмент,
> > "интерпретирующий" setup.py -- python*-module-setuptools.
> > 
> > Подробности: Если используются макросы %python_build/install (обращающиеся
> > к setup.py), то с большой вероятностью используются setuptools. (Вреда от
> > их наличия не будет.)
> 
> Хорошо, что теперь можно не указывать setuptools. Но объясните, почему при его
> указании он не находится:
> 
> <13>Jul  3 11:16:17 rpmi: python-modules-distutils-2.7.14-alt7 1530486275
> installed
> <13>Jul  3 11:16:17 rpmi: libnsl2-devel-1.1.0-alt1_1 1511548748 installed
> <13>Jul  3 11:16:17 rpmi: python-dev-2.7.14-alt7 1530486275 installed
> <13>Jul  3 11:16:17 rpmi: python-module-mysql-2.1.7-alt1 1528642037 installed
> error: failed build dependencies:
> 	python-module-setuptools   is needed by mysql-utilities-1.6.5-alt1
> Installing mysql-utilities-1.6.5-alt1.src.rpm

Расскажите, это сборка какой командой была начата? Тогда могу подробнее 
объяснить.

> > 2. Обоснование изменений в python-dev и python*-module-setuptools: просто
> > распилить на части, которые в разных ситуациях полезны (runtime vs
> > development).
> 
> Напомните заодно про использовать python-dev и python-devel, какой и для чего
> нужен.
> 
> (Конечно, python-dev — крайне неудачное название, вызывающее ненужные
> ассоциации с dev-пакетами Debian)

Это синонимы. Настоящий пакет называется python-dev.

Нужны для сборки бинарных модулей. (Основное понимание предназначения.)

Я читал в ALT-овых документах на тему питона, что рекомендуется писать в 
спеках python-devel (а не -dev).

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

On Tue, 3 Jul 2018, Ivan Zakharyaschev wrote:

> On Tue, 3 Jul 2018, Dmitry V. Levin wrote:
> 
> > On Tue, Jul 03, 2018 at 12:08:22PM +0300, Ivan Zakharyaschev wrote:
> > > Вот такое предложение по изменению в beehive (см. патч), чтобы приблизить 
> > > измерение к ситуации, когда мейнтейнер хочет собрать релиз пакета, потому 
> > > что надо исправить ошибку.
> > > 
> > > Если такое изменение можно внести, хотел бы попросить ещё разок запустить 
> > > пересборку.
> > 
> > OK, пересборка была запущена в 10:25 UTC.
> 
> Спасибо!
> 
> Извините, но результаты плохие, прошу не обращать на них внимание. (Не 
> учитывать в статистике, не рассылать письма.)

Спасибо, что прибил пересборку!

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

On Tue, Jul 03, 2018 at 06:20:42PM +0300, Ivan Zakharyaschev wrote:
> On Tue, 3 Jul 2018, Dmitry V. Levin wrote:
> 
> > On Tue, Jul 03, 2018 at 12:08:22PM +0300, Ivan Zakharyaschev wrote:
> > > Вот такое предложение по изменению в beehive (см. патч), чтобы приблизить 
> > > измерение к ситуации, когда мейнтейнер хочет собрать релиз пакета, потому 
> > > что надо исправить ошибку.
> > > 
> > > Если такое изменение можно внести, хотел бы попросить ещё разок запустить 
> > > пересборку.
> > 
> > OK, пересборка была запущена в 10:25 UTC.
> 
> Спасибо!
> 
> Извините, но результаты плохие, прошу не обращать на них внимание. (Не 
> учитывать в статистике, не рассылать письма.)
> 
> Причина простая:
> 
> Wrote: /usr/src/RPM/RPMS/x86_64/0ad-0.0.23-alt2.x86_64.rpm
> Wrote: /usr/src/RPM/RPMS/x86_64/0ad-debuginfo-0.0.23-alt2.x86_64.rpm
> 2193.03user 128.40system 10:20.07elapsed 374%CPU (0avgtext+0avgdata 
> 808516maxresident)k
> 0inputs+0outputs (0major+42888514minor)pagefaults 0swaps
> sisyphus_check: check-packager ERROR: packager name violation
> /.out/0ad-0.0.23-alt2.src.rpm: wrong PACKAGER: Automated package hasher 
> <hasher@localhost>
> hsh-rebuild: 0ad-0.0.23-alt2.src.rpm: sisyphus_check failed.
> Command exited with non-zero status 1
> 
> 
> .src.rpm не проходит sisyphus_check. Я ещё поизучаю код beehive и hasher, 
> и попробую предложить работающее изменение для beehive. (Локально этого не 
> заметил.)
> 
> Пока прошу откатить изменение в beehive.

Есть прогресс какой-нибудь?
У нас уже 2 дня результаты тестовой пересборки лишены смысла.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] not real rebuild errors, cf. --query-repackage; Re: rpm-4.13.0.1-alt2: Sisyphus/x86_64 test rebuild failed

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

On Wed, 4 Jul 2018, Dmitry V. Levin wrote:

> On Tue, Jul 03, 2018 at 06:20:42PM +0300, Ivan Zakharyaschev wrote:
> > On Tue, 3 Jul 2018, Dmitry V. Levin wrote:
> > 
> > > On Tue, Jul 03, 2018 at 12:08:22PM +0300, Ivan Zakharyaschev wrote:
> > > > Вот такое предложение по изменению в beehive (см. патч), чтобы приблизить 
> > > > измерение к ситуации, когда мейнтейнер хочет собрать релиз пакета, потому 
> > > > что надо исправить ошибку.
> > > > 
> > > > Если такое изменение можно внести, хотел бы попросить ещё разок запустить 
> > > > пересборку.
> > > 
> > > OK, пересборка была запущена в 10:25 UTC.
> > 
> > Спасибо!
> > 
> > Извините, но результаты плохие, прошу не обращать на них внимание. (Не 
> > учитывать в статистике, не рассылать письма.)
> > 
> > Причина простая:
> > 
> > Wrote: /usr/src/RPM/RPMS/x86_64/0ad-0.0.23-alt2.x86_64.rpm
> > Wrote: /usr/src/RPM/RPMS/x86_64/0ad-debuginfo-0.0.23-alt2.x86_64.rpm
> > 2193.03user 128.40system 10:20.07elapsed 374%CPU (0avgtext+0avgdata 
> > 808516maxresident)k
> > 0inputs+0outputs (0major+42888514minor)pagefaults 0swaps
> > sisyphus_check: check-packager ERROR: packager name violation
> > /.out/0ad-0.0.23-alt2.src.rpm: wrong PACKAGER: Automated package hasher 
> > <hasher@localhost>
> > hsh-rebuild: 0ad-0.0.23-alt2.src.rpm: sisyphus_check failed.
> > Command exited with non-zero status 1
> > 
> > 
> > .src.rpm не проходит sisyphus_check. Я ещё поизучаю код beehive и hasher, 
> > и попробую предложить работающее изменение для beehive. (Локально этого не 
> > заметил.)
> > 
> > Пока прошу откатить изменение в beehive.
> 
> Есть прогресс какой-нибудь?
> У нас уже 2 дня результаты тестовой пересборки лишены смысла.

Посмотрел hasher, собираюсь рпедложить изменение.

-- 
Best regards,
Ivan

[devel] I: возможный откат Сизифа на состояние от 20180626

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

On Wed, Jul 04, 2018 at 10:31:00PM +0300, Ivan Zakharyaschev wrote:
> On Wed, 4 Jul 2018, Dmitry V. Levin wrote:
[...]
> > Есть прогресс какой-нибудь?
> > У нас уже 2 дня результаты тестовой пересборки лишены смысла.
> 
> Посмотрел hasher, собираюсь рпедложить изменение.

К сожалению, никакого предложения не получил; пока воткнул хак,
на который мне больно смотреть, и который исчезнет после ребута.

Очередная тестовая пересборка выдала 439 пакетов с новой однотипной ошибкой сборки:
pkg_resources.DistributionNotFound: The 'idna<2.7,>=2.5' distribution was not found

Смотрите, что происходит последние несколько дней с пересобираемостью Сизифа:
0627: +188 -12 (606): setup.rb:1400:in `install_gemspec': undefined method `to_ruby' for nil:NilClass
0629: +295 -192 (713): pkg_resources.DistributionNotFound: The 'setuptools' distribution was not found
0703: +442 -30 (1066): error: failed build dependencies: python-module-setuptools
0705: +325 -496 (894): pkg_resources.DistributionNotFound: The 'idna<2.7,>=2.5' distribution was not found

Я теперь уже не понимаю, какие именно пакеты мне точечно откатывать.
Мне не хотелось бы откатывать весь Сизиф на 0626, конечно.
Но если завтрашняя тестовая пересборка покажет, что проблемы, созданные
за последние несколько дней, не были исправлены, то другого варианта у меня нет.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Vitaly Lipatov]

Dmitry V. Levin писал 5.7.18 11:00:
> On Wed, Jul 04, 2018 at 10:31:00PM +0300, Ivan Zakharyaschev wrote:
>> On Wed, 4 Jul 2018, Dmitry V. Levin wrote:
> [...]
>> > Есть прогресс какой-нибудь?
>> > У нас уже 2 дня результаты тестовой пересборки лишены смысла.
...
> 0705: +325 -496 (894): pkg_resources.DistributionNotFound: The
> 'idna<2.7,>=2.5' distribution was not found
> 
> Я теперь уже не понимаю, какие именно пакеты мне точечно откатывать.
> Мне не хотелось бы откатывать весь Сизиф на 0626, конечно.
> Но если завтрашняя тестовая пересборка покажет, что проблемы, созданные
> за последние несколько дней, не были исправлены, то другого варианта у 
> меня нет.
А у меня есть другой вариант.
Подумаешь, немного модулей python перестало пересобираться. Чему это 
мешает, если это на несколько дней только?

Возможно, есть какие-то причины для паники, которые мне неизвестны?

Если бы была цель держать количество непересобирающихся пакетов в Сизифе 
на минимуме,
то у нас была бы возможность тестировать пересборку после таких 
изменений на копии Сизифа, а не там, где параллельно обновляется kernel, 
plasma и KDE.



-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

On Thu, Jul 05, 2018 at 11:48:36AM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 5.7.18 11:00:
> > On Wed, Jul 04, 2018 at 10:31:00PM +0300, Ivan Zakharyaschev wrote:
> >> On Wed, 4 Jul 2018, Dmitry V. Levin wrote:
> > [...]
> >> > Есть прогресс какой-нибудь?
> >> > У нас уже 2 дня результаты тестовой пересборки лишены смысла.
> ...
> > 0705: +325 -496 (894): pkg_resources.DistributionNotFound: The
> > 'idna<2.7,>=2.5' distribution was not found
> > 
> > Я теперь уже не понимаю, какие именно пакеты мне точечно откатывать.
> > Мне не хотелось бы откатывать весь Сизиф на 0626, конечно.
> > Но если завтрашняя тестовая пересборка покажет, что проблемы, созданные
> > за последние несколько дней, не были исправлены, то другого варианта у 
> > меня нет.
> А у меня есть другой вариант.
> Подумаешь, немного модулей python перестало пересобираться. Чему это 
> мешает, если это на несколько дней только?

Если подумать, то страдают сотни пакетов, не только модули python,
и каждый день разные.

> Возможно, есть какие-то причины для паники, которые мне неизвестны?

Пересобираемость -- ключевая характеристика репозитория.

> Если бы была цель держать количество непересобирающихся пакетов в Сизифе 
> на минимуме,
> то у нас была бы возможность тестировать пересборку после таких 
> изменений на копии Сизифа, а не там, где параллельно обновляется kernel, 
> plasma и KDE.

Конечно, только у вас перепутана причина со следствием.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Sergey V Turchin]

On Thursday, 5 July 2018 11:00:13 MSK Dmitry V wrote:

[...]
> Но если завтрашняя тестовая пересборка покажет, что проблемы, созданные
> за последние несколько дней, не были исправлены, то другого варианта у меня
> нет.
Есть. Подождать исправлений. Разве уже началась предбранчевая стабилизация 
Сиизфа?

-- 
Regards, Sergey.

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

On Thu, Jul 05, 2018 at 12:15:12PM +0300, Sergey V Turchin wrote:
> On Thursday, 5 July 2018 11:00:13 MSK Dmitry V wrote:
> 
> [...]
> > Но если завтрашняя тестовая пересборка покажет, что проблемы, созданные
> > за последние несколько дней, не были исправлены, то другого варианта у меня
> > нет.
> Есть. Подождать исправлений.

Заждались уже.  Сроков нет, ответственных нет.  Увы, не вариант.

> Разве уже началась предбранчевая стабилизация Сиизфа?

Разве нет? ;)

На самом деле есть принципиальная разница между плановым обновлением
компонент (например, gcc, того же python), которые вызывают ожидаемые
сборочные регрессии в репозитории, и непонятными изменениями, сделанными
непонятно зачем, которые вызывают сборочные регрессии, измеряемые сотнями
пакетов, и которые непонятно кто, когда, и как исправит.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Sergey V Turchin]

On Thursday, 5 July 2018 12:22:29 MSK Dmitry V wrote:

[...]
> > Есть. Подождать исправлений.
> Заждались уже.
Точно во множественном числе? ;-)

> Сроков нет, ответственных нет.  Увы, не вариант.
Пока не горит, вполне вариант.

[...]
> > Разве уже началась предбранчевая стабилизация Сиизфа?
> Разве нет? ;)
Нет. Не было анонса.

-- 
Regards, Sergey.

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Michael Shigorin]

On Thu, Jul 05, 2018 at 12:22:29PM +0300, Dmitry V. Levin wrote:
> > Есть. Подождать исправлений.
> Заждались уже.  Сроков нет, ответственных нет.  Увы, не вариант.

Дим, это же сизиф!

> На самом деле есть принципиальная разница между плановым
> обновлением компонент (например, gcc, того же python), которые
> вызывают ожидаемые сборочные регрессии в репозитории, и
> непонятными изменениями, сделанными непонятно зачем, которые
> вызывают сборочные регрессии, измеряемые сотнями пакетов,
> и которые непонятно кто, когда, и как исправит.

Это для тебя или когда ты соизволишь ещё кому рассказать заранее.
Бывало всё-таки иначе, давай как-то стандарт один выводить.
Ваня тоже хочет как лучше.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

On Thu, Jul 05, 2018 at 12:43:44PM +0300, Michael Shigorin wrote:
> On Thu, Jul 05, 2018 at 12:22:29PM +0300, Dmitry V. Levin wrote:
> > > Есть. Подождать исправлений.
> > Заждались уже.  Сроков нет, ответственных нет.  Увы, не вариант.
> 
> Дим, это же сизиф!

Тем более, что это Сизиф.
В ваших приватных репозиториях вы и так уже можете делать что угодно.

> > На самом деле есть принципиальная разница между плановым
> > обновлением компонент (например, gcc, того же python), которые
> > вызывают ожидаемые сборочные регрессии в репозитории, и
> > непонятными изменениями, сделанными непонятно зачем, которые
> > вызывают сборочные регрессии, измеряемые сотнями пакетов,
> > и которые непонятно кто, когда, и как исправит.
> 
> Это для тебя или когда ты соизволишь ещё кому рассказать заранее.
> Бывало всё-таки иначе, давай как-то стандарт один выводить.
> Ваня тоже хочет как лучше.

Если бы Ваня сделал как лучше, то он бы сперва протестировал свои
изменения в песочнице, а после таких регрессий быстро исправил бы либо
откатил изменения.  Полная тестовая пересборка Сизифа сейчас занимает
меньше времени, чем раньше.  Мне неизвестно, что заставило Ваню сделать
не так, как он обычно делает, а так, как он сделал.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Michael Shigorin]

On Thu, Jul 05, 2018 at 12:58:59PM +0300, Dmitry V. Levin wrote:
> On Thu, Jul 05, 2018 at 12:43:44PM +0300, Michael Shigorin wrote:
> > On Thu, Jul 05, 2018 at 12:22:29PM +0300, Dmitry V. Levin wrote:
> > > > Есть. Подождать исправлений.
> > > Заждались уже.  Сроков нет, ответственных нет.  Увы, не вариант.
> > Дим, это же сизиф!
> Тем более, что это Сизиф.

Это были твои слова с предыдущих аналогичных случаев, если что.
Просто в исполнении не Вани, а твоём.

Давай чуточку наберёмся терпения, а не давления.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Anton Farygin]

05.07.2018 11:00, Dmitry V. Levin пишет:
> On Wed, Jul 04, 2018 at 10:31:00PM +0300, Ivan Zakharyaschev wrote:
>> On Wed, 4 Jul 2018, Dmitry V. Levin wrote:
> [...]
>>> Есть прогресс какой-нибудь?
>>> У нас уже 2 дня результаты тестовой пересборки лишены смысла.
>> Посмотрел hasher, собираюсь рпедложить изменение.
> К сожалению, никакого предложения не получил; пока воткнул хак,
> на который мне больно смотреть, и который исчезнет после ребута.
>
> Очередная тестовая пересборка выдала 439 пакетов с новой однотипной ошибкой сборки:
> pkg_resources.DistributionNotFound: The 'idna<2.7,>=2.5' distribution was not found
>
> Смотрите, что происходит последние несколько дней с пересобираемостью Сизифа:
> 0627: +188 -12 (606): setup.rb:1400:in `install_gemspec': undefined method `to_ruby' for nil:NilClass
> 0629: +295 -192 (713): pkg_resources.DistributionNotFound: The 'setuptools' distribution was not found
> 0703: +442 -30 (1066): error: failed build dependencies: python-module-setuptools
> 0705: +325 -496 (894): pkg_resources.DistributionNotFound: The 'idna<2.7,>=2.5' distribution was not found
>
> Я теперь уже не понимаю, какие именно пакеты мне точечно откатывать.
> Мне не хотелось бы откатывать весь Сизиф на 0626, конечно.
> Но если завтрашняя тестовая пересборка покажет, что проблемы, созданные
> за последние несколько дней, не были исправлены, то другого варианта у меня нет.

Ну потерпи немного, сейчас Лёша Никифоров выйдет с больничного и 
посмотрит что там происходит.

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Anton Farygin]

05.07.2018 12:58, Dmitry V. Levin пишет:
> Если бы Ваня сделал как лучше, то он бы сперва протестировал свои
> изменения в песочнице, а после таких регрессий быстро исправил бы либо
> откатил изменения.  Полная тестовая пересборка Сизифа сейчас занимает
> меньше времени, чем раньше.  Мне неизвестно, что заставило Ваню сделать
> не так, как он обычно делает, а так, как он сделал.

Ты имеешь возможность обсудить с ним это в офисе.

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]

On Thu, 5 Jul 2018, Dmitry V. Levin wrote:

> On Wed, Jul 04, 2018 at 10:31:00PM +0300, Ivan Zakharyaschev wrote:
> > On Wed, 4 Jul 2018, Dmitry V. Levin wrote:
> [...]
> > > Есть прогресс какой-нибудь?
> > > У нас уже 2 дня результаты тестовой пересборки лишены смысла.
> > 
> > Посмотрел hasher, собираюсь рпедложить изменение.
> 
> К сожалению, никакого предложения не получил; пока воткнул хак,
> на который мне больно смотреть, и который исчезнет после ребута.

Хотел предложить такое, как в патче. (Сохранять PACKAGER при 
--query-repackage). Мне надо ещё протестировать, как оно работает.

> Очередная тестовая пересборка выдала 439 пакетов с новой однотипной ошибкой сборки:
> pkg_resources.DistributionNotFound: The 'idna<2.7,>=2.5' distribution was not found

Это уже похоже на реальную проблему (после моих измениний в сумме пакеты 
пересобирались, т.е. это не мешало работе мейнтейнеров, но beehive не 
мог). А с тех пор, как они пересобирались локально в hasher, я вроде 
изменений не вносил в Sisyphus, и эта новая ошибка связана, наверное, не с 
моими изменениями, а чем-то в районе requests.

> Смотрите, что происходит последние несколько дней с пересобираемостью Сизифа:
> 0627: +188 -12 (606): setup.rb:1400:in `install_gemspec': undefined method `to_ruby' for nil:NilClass
> 0629: +295 -192 (713): pkg_resources.DistributionNotFound: The 'setuptools' distribution was not found
> 0703: +442 -30 (1066): error: failed build dependencies: python-module-setuptools
> 0705: +325 -496 (894): pkg_resources.DistributionNotFound: The 'idna<2.7,>=2.5' distribution was not found
> 
> Я теперь уже не понимаю, какие именно пакеты мне точечно откатывать.
> Мне не хотелось бы откатывать весь Сизиф на 0626, конечно.
> Но если завтрашняя тестовая пересборка покажет, что проблемы, созданные
> за последние несколько дней, не были исправлены, то другого варианта у меня нет.


-- 
Best regards,
Ivan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch; name=0001-save-PACKAGER-in-during-query-repackage.patch, Size: 1074 bytes --]

From 357fde47190c9cd7bed1b4b5d23f36a19c2e52ed Mon Sep 17 00:00:00 2001
From: Ivan Zakharyaschev <imz@altlinux.org>
Date: Thu, 5 Jul 2018 18:42:12 +0300
Subject: [PATCH] save PACKAGER in during --query-repackage

PACKAGER is already set to the original value during normal hasher
operation when building new packages.

But the original value was lost with --query-repackage, and so the
resulting rebuilt packages always differed from what the results of
normal hasher operation would be.
---
 hasher/hsh-rebuild | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/hasher/hsh-rebuild b/hasher/hsh-rebuild
index e9eedf9..59de7fc 100755
--- a/hasher/hsh-rebuild
+++ b/hasher/hsh-rebuild
@@ -215,6 +215,10 @@ if [ -z "$nodeps" ]; then
 		create_entry_header
 		cat >>"$entry" <<__EOF__
 cd "\$HOME/in/srpm"
+packager=\$(rpmquery -p --qf '%{PACKAGER}' *)
+cat >>"\$HOME/.rpmmacros" <<EOF
+%packager \$packager
+EOF
 ${rpmi:-$def_rpmi} -i -- *
 cd \`rpm --eval %_specdir\`
 sed '/^buildrequires(pre):[[:space:]]*/I!d;s///' *.spec |
-- 
2.10.4

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Thu, 5 Jul 2018, Ivan Zakharyaschev wrote:

> On Thu, 5 Jul 2018, Dmitry V. Levin wrote:
> 
> > On Wed, Jul 04, 2018 at 10:31:00PM +0300, Ivan Zakharyaschev wrote:
> > > On Wed, 4 Jul 2018, Dmitry V. Levin wrote:
> > [...]
> > > > Есть прогресс какой-нибудь?
> > > > У нас уже 2 дня результаты тестовой пересборки лишены смысла.
> > > 
> > > Посмотрел hasher, собираюсь рпедложить изменение.
> > 
> > К сожалению, никакого предложения не получил; пока воткнул хак,
> > на который мне больно смотреть, и который исчезнет после ребута.
> 
> Хотел предложить такое, как в патче. (Сохранять PACKAGER при 
> --query-repackage). Мне надо ещё протестировать, как оно работает.

ldv@ поделился опытом, что этого недостаточно. Нужно делать 
многоступенчато, как с tar.

-- 
Best regards,
Ivan

Re: [devel] откат python*-module-idna для починки sphinx

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

On Thu, Jul 05, 2018 at 11:00:13AM +0300, Dmitry V. Levin wrote:
[...]
> 0705: +325 -496 (894): pkg_resources.DistributionNotFound: The 'idna<2.7,>=2.5' distribution was not found

А вот и изменение сборочной среды, которое к этому привело:
-<13>Jul  3 23:13:44 rpmi: python-module-idna-2.6-alt1 1521037014 installed
+<13>Jul  5 02:24:39 rpmi: python-module-idna-2.7-alt1 1530720902 installed
-<13>Jul  3 23:07:58 rpmi: python3-module-idna-2.6-alt1 1521037014 installed
+<13>Jul  5 01:58:26 rpmi: python3-module-idna-2.7-alt1 1530720902 installed

От этого изменения пострадала сборка 439 пакетов.

Получается, что нужно либо незамедлительно обновить sphinx до той версии,
которая поддерживает python*-module-idna-2.7, либо незамедлительно откатить
python*-module-idna на прежнюю версию.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] откат python*-module-idna для починки sphinx

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

On Fri, Jul 06, 2018 at 12:20:00AM +0300, Dmitry V. Levin wrote:
> On Thu, Jul 05, 2018 at 11:00:13AM +0300, Dmitry V. Levin wrote:
> [...]
> > 0705: +325 -496 (894): pkg_resources.DistributionNotFound: The 'idna<2.7,>=2.5' distribution was not found
> 
> А вот и изменение сборочной среды, которое к этому привело:
> -<13>Jul  3 23:13:44 rpmi: python-module-idna-2.6-alt1 1521037014 installed
> +<13>Jul  5 02:24:39 rpmi: python-module-idna-2.7-alt1 1530720902 installed
> -<13>Jul  3 23:07:58 rpmi: python3-module-idna-2.6-alt1 1521037014 installed
> +<13>Jul  5 01:58:26 rpmi: python3-module-idna-2.7-alt1 1530720902 installed
> 
> От этого изменения пострадала сборка 439 пакетов.
> 
> Получается, что нужно либо незамедлительно обновить sphinx до той версии,
> которая поддерживает python*-module-idna-2.7, либо незамедлительно откатить
> python*-module-idna на прежнюю версию.

s/sphinx/python*-module-requests/


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] откат python*-module-idna для починки sphinx

[Vladimir Didenko]

пт, 6 июл. 2018 г. в 0:48, Dmitry V. Levin:
>
> s/sphinx/python*-module-requests/

Увидел, что python-requests обновился до 2.19.1, только бомба
по-прежнему осталось, даже несколько. Из setup.py

requires = [
    'chardet>=3.0.2,<3.1.0',
    'idna>=2.5,<2.8',
    'urllib3>=1.21.1,<1.24',
    'certifi>=2017.4.17'
]

Предлагаю сделать одно из следующих изменений:

1. Поставить явные зависимости RPM с ограничениями на версию
(например, Requires: python-module-idna < 2.8). Спасет от мэйнтейнеров
chardet, idna, urllib3. Но не спасет от мэйнтейнеров, которые будут
обновлять python-requests вслепую, не тестируя.
2. Убрать в зависимостях setup.py ограничения '<'. Я так делаю с
docker-compose, поскольку эти ограничения ничем не обоснованы.  Спасет
от мэйнтейнеров chardet, idna, urllib3, а также и от обновляющих
python-requests. Единственный минус - не покрывается ситуация, когда
при обновлении одного из пакетов совместимость действительно будет
сломана.
3. Собирать python-requests с bundled библиотеками. Спасет всех, но c
идеологической сторорны выглядит не очень.

Лично я за пункт 2, но готов выслушать другие мнения.

-- 
С уважением,
Владимир.

Re: [devel] откат python*-module-idna для починки sphinx

[Andrey Cherepanov]

06.07.2018 00:48, Dmitry V. Levin пишет:
> On Fri, Jul 06, 2018 at 12:20:00AM +0300, Dmitry V. Levin wrote:
>> On Thu, Jul 05, 2018 at 11:00:13AM +0300, Dmitry V. Levin wrote:
>> [...]
>>> 0705: +325 -496 (894): pkg_resources.DistributionNotFound: The 'idna<2.7,>=2.5' distribution was not found
>> А вот и изменение сборочной среды, которое к этому привело:
>> -<13>Jul  3 23:13:44 rpmi: python-module-idna-2.6-alt1 1521037014 installed
>> +<13>Jul  5 02:24:39 rpmi: python-module-idna-2.7-alt1 1530720902 installed
>> -<13>Jul  3 23:07:58 rpmi: python3-module-idna-2.6-alt1 1521037014 installed
>> +<13>Jul  5 01:58:26 rpmi: python3-module-idna-2.7-alt1 1530720902 installed
>>
>> От этого изменения пострадала сборка 439 пакетов.
>>
>> Получается, что нужно либо незамедлительно обновить sphinx до той версии,
>> которая поддерживает python*-module-idna-2.7, либо незамедлительно откатить
>> python*-module-idna на прежнюю версию.
> s/sphinx/python*-module-requests/
Уже давно висит
208363 TESTED #5 [test-only] sisyphus python-module-requests.git=2.19.1-alt1

Могу хоть сейчас отправить.

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] откат python*-module-idna для починки sphinx

[Anton Farygin]

06.07.2018 11:30, Andrey Cherepanov пишет:
> 06.07.2018 00:48, Dmitry V. Levin пишет:
>> On Fri, Jul 06, 2018 at 12:20:00AM +0300, Dmitry V. Levin wrote:
>>> On Thu, Jul 05, 2018 at 11:00:13AM +0300, Dmitry V. Levin wrote:
>>> [...]
>>>> 0705: +325 -496 (894): pkg_resources.DistributionNotFound: The 'idna<2.7,>=2.5' distribution was not found
>>> А вот и изменение сборочной среды, которое к этому привело:
>>> -<13>Jul  3 23:13:44 rpmi: python-module-idna-2.6-alt1 1521037014 installed
>>> +<13>Jul  5 02:24:39 rpmi: python-module-idna-2.7-alt1 1530720902 installed
>>> -<13>Jul  3 23:07:58 rpmi: python3-module-idna-2.6-alt1 1521037014 installed
>>> +<13>Jul  5 01:58:26 rpmi: python3-module-idna-2.7-alt1 1530720902 installed
>>>
>>> От этого изменения пострадала сборка 439 пакетов.
>>>
>>> Получается, что нужно либо незамедлительно обновить sphinx до той версии,
>>> которая поддерживает python*-module-idna-2.7, либо незамедлительно откатить
>>> python*-module-idna на прежнюю версию.
>> s/sphinx/python*-module-requests/
> Уже давно висит
> 208363 TESTED #5 [test-only] sisyphus python-module-requests.git=2.19.1-alt1
>
> Могу хоть сейчас отправить.
>
Сейчас сизиф разломан настолько, что его даже проверить не на чем.

Re: [devel] python-requests

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

On Fri, Jul 06, 2018 at 09:05:05AM +0300, Vladimir Didenko wrote:
> Увидел, что python-requests обновился до 2.19.1, только бомба
> по-прежнему осталось, даже несколько. Из setup.py
> 
> requires = [
>     'chardet>=3.0.2,<3.1.0',
>     'idna>=2.5,<2.8',
>     'urllib3>=1.21.1,<1.24',
>     'certifi>=2017.4.17'
> ]
> 
> Предлагаю сделать одно из следующих изменений:
> 
> 1. Поставить явные зависимости RPM с ограничениями на версию
> (например, Requires: python-module-idna < 2.8). Спасет от мэйнтейнеров
> chardet, idna, urllib3. Но не спасет от мэйнтейнеров, которые будут
> обновлять python-requests вслепую, не тестируя.
> 2. Убрать в зависимостях setup.py ограничения '<'. Я так делаю с
> docker-compose, поскольку эти ограничения ничем не обоснованы.  Спасет
> от мэйнтейнеров chardet, idna, urllib3, а также и от обновляющих
> python-requests. Единственный минус - не покрывается ситуация, когда
> при обновлении одного из пакетов совместимость действительно будет
> сломана.
> 3. Собирать python-requests с bundled библиотеками. Спасет всех, но c
> идеологической сторорны выглядит не очень.
> 
> Лично я за пункт 2, но готов выслушать другие мнения.

Ранее уже было озвучено предложение:
- генерить зависимости из requires[] автоматически;
- если requires[] кривые, то патчить.

Но главное, конечно - включить в пакете тесты!


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] python-requests

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]

On Fri, 6 Jul 2018, Dmitry V. Levin wrote:

> On Fri, Jul 06, 2018 at 09:05:05AM +0300, Vladimir Didenko wrote:
> > Увидел, что python-requests обновился до 2.19.1, только бомба
> > по-прежнему осталось, даже несколько. Из setup.py
> > 
> > requires = [
> >     'chardet>=3.0.2,<3.1.0',
> >     'idna>=2.5,<2.8',
> >     'urllib3>=1.21.1,<1.24',
> >     'certifi>=2017.4.17'
> > ]
> > 
> > Предлагаю сделать одно из следующих изменений:
> > 
> > 1. Поставить явные зависимости RPM с ограничениями на версию
> > (например, Requires: python-module-idna < 2.8). Спасет от мэйнтейнеров
> > chardet, idna, urllib3. Но не спасет от мэйнтейнеров, которые будут
> > обновлять python-requests вслепую, не тестируя.
> > 2. Убрать в зависимостях setup.py ограничения '<'. Я так делаю с
> > docker-compose, поскольку эти ограничения ничем не обоснованы.  Спасет
> > от мэйнтейнеров chardet, idna, urllib3, а также и от обновляющих
> > python-requests. Единственный минус - не покрывается ситуация, когда
> > при обновлении одного из пакетов совместимость действительно будет
> > сломана.
> > 3. Собирать python-requests с bundled библиотеками. Спасет всех, но c
> > идеологической сторорны выглядит не очень.
> > 
> > Лично я за пункт 2, но готов выслушать другие мнения.
> 
> Ранее уже было озвучено предложение:
> - генерить зависимости из requires[] автоматически;
> - если requires[] кривые, то патчить.

Да, так бы я и сформулировал и своё сложившееся понимание этого вопроса.

Последнее обсуждение не попало в devel@; viy@ рассказал:

----------

> Игорь, вот помните Ваше предложение по отслеживанию с помощью
> авто-reqs/provs того, что написано в *.egginfo?
>
> Видимо, это стоит реализовать. Нет ли у Вас готовых нароботок уже?

Это реализовано в mageia, оттуда можно взять готовое решение.
Provides вида pythonegg(2)(distro)  в python2-distro

Но похоже намечается новый стандарт -
В федоре и магее появились очень интересные provides вида
python2/3dist(...) с приведенным именем модуля в pypi.
python2dist(aaargh)   python2-aaargh
python2dist(abclient) python2-abclient
python3dist(achoo)    python3-achoo

---------

imz@: Ввод нового вида Provides/Requires будет немного 
болезненнным/потербует некоторого времени для ввода: прежде, чем 
использовать Requires, нужно сгенерировать Provides в других пакетах. 
(Вариант отображть имя egginfo-файла в имя пакета по таблице мне кажется 
не очень честным: пр перетасовке файлов или переименовании пакетов старые 
Requires будут недействительными. Хотя сейчас это так делается для 
некоторых видов зависимостей -- по contents_index; но это мн етоже кажется 
неидеальным.)

Подумал ещё о варианте превращать это в файловые зависимости, но такое 
простое решение сработает плохо, потому что egginfo-файлы могут лежать в 
разных директориях у нас (по крайней мере: внтури /usr/lib или 
/usr/lib64). Может быть, унификация и возможна, но это такой же 
необходимый первый этап, как и генерация Provides в первом варианте.

-- 
Best regards,
Ivan

Re: [devel] откат python*-module-idna для починки sphinx

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Fri, Jul 06, 2018 at 11:30:01AM +0300, Andrey Cherepanov wrote:
> 06.07.2018 00:48, Dmitry V. Levin пишет:
> > On Fri, Jul 06, 2018 at 12:20:00AM +0300, Dmitry V. Levin wrote:
> >> On Thu, Jul 05, 2018 at 11:00:13AM +0300, Dmitry V. Levin wrote:
> >> [...]
> >>> 0705: +325 -496 (894): pkg_resources.DistributionNotFound: The 'idna<2.7,>=2.5' distribution was not found
> >> А вот и изменение сборочной среды, которое к этому привело:
> >> -<13>Jul  3 23:13:44 rpmi: python-module-idna-2.6-alt1 1521037014 installed
> >> +<13>Jul  5 02:24:39 rpmi: python-module-idna-2.7-alt1 1530720902 installed
> >> -<13>Jul  3 23:07:58 rpmi: python3-module-idna-2.6-alt1 1521037014 installed
> >> +<13>Jul  5 01:58:26 rpmi: python3-module-idna-2.7-alt1 1530720902 installed
> >>
> >> От этого изменения пострадала сборка 439 пакетов.
> >>
> >> Получается, что нужно либо незамедлительно обновить sphinx до той версии,
> >> которая поддерживает python*-module-idna-2.7, либо незамедлительно откатить
> >> python*-module-idna на прежнюю версию.
> > s/sphinx/python*-module-requests/
> Уже давно висит
> 208363 TESTED #5 [test-only] sisyphus python-module-requests.git=2.19.1-alt1
> 
> Могу хоть сейчас отправить.

Это уже поздно отправлять.  Что надо, так это тесты в пакете включить.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] python-requests

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]

On Fri, Jul 06, 2018 at 01:00:12PM +0300, Ivan Zakharyaschev wrote:
> On Fri, 6 Jul 2018, Dmitry V. Levin wrote:
> 
> > On Fri, Jul 06, 2018 at 09:05:05AM +0300, Vladimir Didenko wrote:
> > > Увидел, что python-requests обновился до 2.19.1, только бомба
> > > по-прежнему осталось, даже несколько. Из setup.py
> > > 
> > > requires = [
> > >     'chardet>=3.0.2,<3.1.0',
> > >     'idna>=2.5,<2.8',
> > >     'urllib3>=1.21.1,<1.24',
> > >     'certifi>=2017.4.17'
> > > ]
> > > 
> > > Предлагаю сделать одно из следующих изменений:
> > > 
> > > 1. Поставить явные зависимости RPM с ограничениями на версию
> > > (например, Requires: python-module-idna < 2.8). Спасет от мэйнтейнеров
> > > chardet, idna, urllib3. Но не спасет от мэйнтейнеров, которые будут
> > > обновлять python-requests вслепую, не тестируя.
> > > 2. Убрать в зависимостях setup.py ограничения '<'. Я так делаю с
> > > docker-compose, поскольку эти ограничения ничем не обоснованы.  Спасет
> > > от мэйнтейнеров chardet, idna, urllib3, а также и от обновляющих
> > > python-requests. Единственный минус - не покрывается ситуация, когда
> > > при обновлении одного из пакетов совместимость действительно будет
> > > сломана.
> > > 3. Собирать python-requests с bundled библиотеками. Спасет всех, но c
> > > идеологической сторорны выглядит не очень.
> > > 
> > > Лично я за пункт 2, но готов выслушать другие мнения.
> > 
> > Ранее уже было озвучено предложение:
> > - генерить зависимости из requires[] автоматически;
> > - если requires[] кривые, то патчить.
> 
> Да, так бы я и сформулировал и своё сложившееся понимание этого вопроса.
> 
> Последнее обсуждение не попало в devel@; viy@ рассказал:
> 
> ----------
> 
> > Игорь, вот помните Ваше предложение по отслеживанию с помощью
> > авто-reqs/provs того, что написано в *.egginfo?
> >
> > Видимо, это стоит реализовать. Нет ли у Вас готовых нароботок уже?
> 
> Это реализовано в mageia, оттуда можно взять готовое решение.
> Provides вида pythonegg(2)(distro)  в python2-distro
> 
> Но похоже намечается новый стандарт -
> В федоре и магее появились очень интересные provides вида
> python2/3dist(...) с приведенным именем модуля в pypi.
> python2dist(aaargh)   python2-aaargh
> python2dist(abclient) python2-abclient
> python3dist(achoo)    python3-achoo

Зачем им понадобились такие странные provides?
Чем им традиционные python2.7(requests) и python3(requests) не угодили?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] python-requests

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On Fri, 6 Jul 2018, Dmitry V. Levin wrote:

> > ----------
> > 
> > > Игорь, вот помните Ваше предложение по отслеживанию с помощью
> > > авто-reqs/provs того, что написано в *.egginfo?
> > >
> > > Видимо, это стоит реализовать. Нет ли у Вас готовых нароботок уже?
> > 
> > Это реализовано в mageia, оттуда можно взять готовое решение.
> > Provides вида pythonegg(2)(distro)  в python2-distro
> > 
> > Но похоже намечается новый стандарт -
> > В федоре и магее появились очень интересные provides вида
> > python2/3dist(...) с приведенным именем модуля в pypi.
> > python2dist(aaargh)   python2-aaargh
> > python2dist(abclient) python2-abclient
> > python3dist(achoo)    python3-achoo
> 
> Зачем им понадобились такие странные provides?
> Чем им традиционные python2.7(requests) и python3(requests) не угодили?

Традиционные -- это имя модуля, который можно импортировать
(import requests).

А это что-то вроде имени пакета (distribution). Оно, наверное, может не 
совпадать с именем модуля, и именно к имени пакета относится версия.

-- 
Best regards,
Ivan

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]

Hello!

Пока улучшение hasher (ради пересборки в beehive) в процессе (но есть 
активный в beehive хак), можно ознакомиться со списком пакетов, сборка 
которых сломалась после расиливания двух питоновских пакетов 
(python*-module-setuptools и python-dev).

В некоторых местах не хвататет BuildRequires (подробности изучу и напишу в 
каком-нибудь следующем письме).

[imz@team error]$ pwd
/beehive/logs/Sisyphus-i586/archive/2018/0702/error
[imz@team error]$ for f in *; do \
if [ -e ../../0628/error/"$f" ]; then continue; fi; \
if [ -e /beehive/logs/Sisyphus-i586/latest/success/"${f%.zst}" ]; then continue; fi; \
if [ -e /beehive/logs/Sisyphus-i586/latest/error/"${f%.zst}" ]; \
then echo -n 'still broken: '; \
else echo -n 'fixed by someone: '; \
fi; 
echo "${f%.zst} "; \
done | sort
fixed by someone: Mesa-4:18.1.1-alt1.S1 
fixed by someone: brltty-5.6-alt1.1 
fixed by someone: glade-3.22.1-alt1 
fixed by someone: graphviz-2.40.1-alt2 
fixed by someone: hugin-2018.0.0-alt1.1 
fixed by someone: libkafel-1-alt1.gitf664aca 
fixed by someone: libpeas-1.22.0-alt1.1 
fixed by someone: python-module-BeautifulSoup4-4.5.3-alt1 
fixed by someone: python-module-Pillow-5.1.0-alt2 
fixed by someone: python-module-gst1.0-1.14.1-alt1 
fixed by someone: ruby-gettext-3.2.9-alt1.3 
fixed by someone: scribus-1:1.5.4-alt1 
still broken: compiz-0.9.13.1-alt1 
still broken: createrepo_c-0.10.0-alt1 
still broken: fityk-1.3.0-alt4.git20141119.2.1 
still broken: git-2.10.5-alt1 
still broken: gnumeric-1.12.39-alt1 
still broken: httpie-0.9.8-alt2 
still broken: kde4-analitza-4.14.0-alt1 
still broken: kmymoney-5.0.1-alt1 
still broken: ldapvi-1.7-alt2 
still broken: liquidwar6-0.6.3902-alt1.1.qa1 
still broken: ocaml-lwt-4.0.1-alt1.S1 
still broken: opennebula-5.4.15-alt2.S1 
still broken: poezio-0.9-alt4.1 
still broken: python-module-joblib-0.11-alt2 
still broken: python-module-pydap-3.1.1-alt2.git20131114 
still broken: python3-module-pyxattr-docs-0.6.0-alt1 
still broken: shiboken-1.2.2-alt3.git20140422 
still broken: uim-1.8.6-alt4.git89542ac.2 
still broken: w3m-0.5.3-alt1 
still broken: waon-0.10-alt3 
[imz@team error]$ 


-- 
Best regards,
Ivan

Re: [devel] I: возможный откат Сизифа на состояние от 20180626

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

Записал причину про некоторые пакеты, которые посмотрел:

$ sort -k3,3 < 2018-06-python-req-devel-broken.comments.txt'
Mesa-4:18.1.1-alt1.S1 -- fixed by someone
brltty-5.6-alt1.1 -- fixed by someone
glade-3.22.1-alt1 -- fixed by someone
graphviz-2.40.1-alt2 -- fixed by lav@ (python-devel added in 2.40.1-alt3)
hugin-2018.0.0-alt1.1 -- fixed by someone
libkafel-1-alt1.gitf664aca -- fixed by someone
libpeas-1.22.0-alt1.1 -- fixed by aris@ (python-devel added in 
1.22.0-alt2)
python-module-BeautifulSoup4-4.5.3-alt1 -- fixed by imz@ (dropped non-standard %%python_build/install)
python-module-Pillow-5.1.0-alt2 -- fixed by lav@ (in the course of update to 5.2.0-alt1; a simple rebuild would succeed)
python-module-gst1.0-1.14.1-alt1 -- fixed by aris@ (python-devel added in 1.14.1-alt2)
ruby-gettext-3.2.9-alt1.3 -- fixed by someone
scribus-1:1.5.4-alt1 -- fixed by lav@ (in the course of a major spec 
cleanup in 1.5.4-alt2)
compiz-0.9.13.1-alt1 -- still broken
createrepo_c-0.10.0-alt1 -- still broken
fityk-1.3.0-alt4.git20141119.2.1 -- still broken
gnumeric-1.12.39-alt1 -- still broken (python-devel needed)
httpie-0.9.8-alt2 -- still broken
kde4-analitza-4.14.0-alt1 -- still broken
kmymoney-5.0.1-alt1 -- still broken
ldapvi-1.7-alt2 -- still broken
liquidwar6-0.6.3902-alt1.1.qa1 -- still broken
ocaml-lwt-4.0.1-alt1.S1 -- still broken
opennebula-5.4.15-alt2.S1 -- still broken
poezio-0.9-alt4.1 -- still broken
python-module-joblib-0.11-alt2 -- still broken
python-module-pydap-3.1.1-alt2.git20131114 -- still broken
python3-module-pyxattr-docs-0.6.0-alt1 -- still broken
shiboken-1.2.2-alt3.git20140422 -- still broken (python-devel needed)
uim-1.8.6-alt4.git89542ac.2 -- still broken
w3m-0.5.3-alt1 -- still broken (libtinfo-devel needed)
waon-0.10-alt3 -- still broken


-- 
Best regards,
Ivan