[devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Dmitry V. Levin]

Hi,

У сложившейся традиции сопровождения пакетов есть существенный недостаток:
в результате обновлений ломаются сборки пакетов, и эти поломки подолгу
никто не фиксит.
Например, приходит время обновлять тулчейн, а последствия предыдущего
обновления ещё не исправлены.

Для справки, релизы новых версий элементов тулчейна выходят на регулярной основе:
binutils и glibc - 2 раза в год в начале февраля и начале августа,
gcc - раз в год в начале мая.
Другими словами, релиз gcc происходит примерно посередине между релизами
binutils+glibc, т.е. между релизами элементов тулчейна проходит примерно
3 месяца.

Таким образом, для того, чтобы собирать релизы тулчейна регулярно,
нам нужно успевать к очередному релизу исправлять последствия предыдущего релиза.
Это значит, что время исправления должно быть меньше 3 месяцев.

В результате регулярных обновлений тулчейна исправление ftbfs станет более
равномерным и менее нервным процессом, а авральные исправления ftbfs перед
бранчеванием уйдут в прошлое.

Для того, чтобы укладываться с исправлением всех ftbfs в 3 месяца,
я предлагаю следующее изменение в сопровождении пакетов:
- мантейнерам начинать исправлять ftbfs сразу, как только ftbfs возникают;
- сформировать группу мантейнеров, которая будет исправлять ftbfs в
  пакетах других мантейнеров:
  + для пакетов на @nobody - сразу, как только ftbfs возникают;
  + для остальных пакетов - 4 недели спустя после возникновения ftbfs.

Приложение: 3 списка пакетов.

1. Список пакетов на @nobody с ftbfs на архитектуре x86_64:
$ awk '$4=="@nobody" {print}' beehive/stats/Sisyphus-x86_64/ftbfs-joined
daskr	2011.06.08-alt1	15	@nobody
gkrellm-gtodo	0.2.4-alt1	15	@nobody
golang-tools	0-alt7.git24acc66e	5	@nobody
hardinfo	0.6-alt0.1.alpha.gitb2991d7	15	@nobody
hnb	1.9.18-alt1.qa1	15	@nobody
hping2	2.0.0-alt4.rc2.qa3	15	@nobody
icukrell	2.0.0-alt2_pre0.1.qa1	15	@nobody
ipv6calc	0.94.1-alt1	15	@nobody
launchtool	0.7-alt1.qa1	14	@nobody
lazy	0.24d-alt2.qa1	15	@nobody
libcoredumper	1.2.1-alt2.3	14	@nobody
libgdchart	0.11.5-alt1.1.qa1	15	@nobody
libgringotts	1.2.1-alt1.1.qa1	16	@nobody
libslatec	4.1-alt7	15	@nobody
linuxtv-dvb-apps	1.1.1-alt2.2	14	@nobody
log4c	1.2.1-alt1.1.qa1	16	@nobody
ltspfs	0.3-alt4.20070117.qa1	14	@nobody
ltspfsd	0.3-alt0.2.2.qa1	14	@nobody
ltxml	1.2.7-alt2.1	15	@nobody
lush	2.0.1-alt3	16	@nobody
mar	20070301-alt1.qa1	15	@nobody
mct	2.8.3-alt1	15	@nobody
memmapper	1.42-alt1.qa1	15	@nobody
meschach	1.2-alt1.b.3	0	@nobody
musepack	r475-alt2	15	@nobody
nas	1.9.4-alt2.git20131009	15	@nobody
netwalk	0.4.10-alt6	15	@nobody
opentracker	1.6-alt2	16	@nobody
p3nfs	5.19-alt1.qa2	14	@nobody
pidgin-plugin-mrim	0.1.28-alt3	15	@nobody
procinfo	1:18-alt1.qa1	14	@nobody
proxychains	3.1-alt2	15	@nobody
pvm	3.4.6-alt1.1.qa1	16	@nobody
rdate	1.4-alt5.qa1	14	@nobody
scmpc	0.4.1-alt1.git20130304	15	@nobody
sdlscav	145.1_2010_11_5-alt1	15	@nobody
sjog	cvs20040812-alt4.1	15	@nobody
skippy	0.5.0-alt2.qa1	15	@nobody
squidGuard	1.4-alt1.qa1	15	@nobody
squidclam	0.23-alt1	15	@nobody
sven	0.6-alt3	15	@nobody
svox-pico	20120212-alt2	16	@nobody
wmclockmon	0.8.1-alt5.qa1	15	@nobody
xd3d	8.3.1-alt5	15	@nobody

2. Список пакетов не на @nobody с ftbfs от 12 недель на архитектуре x86_64:
$ awk '$3>=12 && $4!="@nobody" {print}' beehive/stats/Sisyphus-x86_64/ftbfs-joined
CBFlib	0.9.2.3-alt2	15	mike,@everybody
angband	4.1.2-alt1	15	george,@qa
apache2	1:2.4.46-alt2	13	rider,@everybody
avro	1.7.6-alt5_5jpp8	23	viy,@everybody
awesome	4.3-alt3	15	evg
babel	2.0.0-alt2.qa2	15	sin,@python,@qa,@everybody
bfgminer	5.5.0-alt1	15	drool,@everybody
biniax2	1.30-alt2.qa1	15	george,@qa
blas	3.9.2-alt2	15	manowar,@everybody
blzpack	04.00-alt11	15	grenka,@everybody
chestnut-dialer	0.3.3-alt8.3	17	mike,darktemplar,@qa
cpio	2.12-alt1	15	@core
cross-gcc	8.2.1-alt1_1.1	16	shaba,@everybody
dsniff	2.4-alt0.13.b1	14	vseleznv
dxx-rebirth	20200301-alt1	15	george,@everybody
elinks	0.12-alt0.12.6	15	george,glebfm,at
emacs-bbdb	2.35-alt3	17	@emacs
emacs-manual-ru	20.7-alt1.qa1	17	@emacs
erlang	1:21.3.6-alt3	15	nbr,shaba
ff-clone	1.2-alt1	15	george,@everybody
freehdl	0.0.8-alt5	16	mithraen,@everybody
fuse-zfs	0.7.2.2-alt1_14	14	viy,@everybody
gcc4.3	4.3.2-alt22	17	glebfm,@everybody
gcc4.9	4.9.2-alt8	14	glebfm
gcc5	5.3.1-alt8	14	glebfm
gcc6	6.3.1-alt6	14	glebfm
gcc7	7.3.1-alt9	14	glebfm
glsl-optimizer	2016.10-alt1.git21b98a9854	15	darktemplar,@everybody
gluegen2	2.3.2-alt1_11jpp8	15	viy,@everybody
goaccess	1.1.1-alt1	15	valintinr,@everybody
gpm	1.20.1-alt18.1	15	@core
gprolog	1.4.5-alt1	15	oddity,@everybody
gravit	0.5.0-alt1.1	15	george,@everybody
grdesktop	0.23-alt0.4	15	lav,mike,@qa
gri	2.12.23-alt6	17	darktemplar,@everybody
grizzly-npn	1.2-alt1_9jpp8	14	viy,@everybody
gumtree	2.1.1-alt1	24	darktemplar,@everybody
gwc	0.21.17-alt2	15	mike,@everybody
gwget	1.0.4-alt4.1	15	shaba,@everybody
hdf	4.2.14-alt1_1	15	oddity,@everybody
hibernate-validator	5.2.4-alt2_6jpp8	14	viy,@everybody
hp2xx	3.4.2-alt1	15	mike,@everybody
hping3	0.0.20051105-alt6	15	evg,@everybody
ht	2.1.0-alt2	15	led,@everybody
i3status	2.9-alt1	15	vkni,@everybody
icestorm	0.0.0.618.gf029975-alt2	15	lineprinter,@everybody
imagewriter	1.10-alt4	14	drool,@everybody
infinispan	8.2.4-alt2_5jpp8	14	viy,@everybody
inn	2.6.3-alt2.1	15	crux,@everybody
iozone	3.489-alt3	15	lav,@qa
ipband	0.8.1-alt1	15	oddity,@everybody
ipsec-tools	0.8.2-alt3	14	shaba,@everybody
iscan-free	2.20.0-alt6	15	lav,@qa,@everybody
iverilog	10.2-alt1	15	lineprinter,@everybody
jabber-muc	0.8.81-alt0.1	15	lakostis,@everybody
jamin	0.95.0-alt2.1	15	george,@qa
jboss-jsf-2.2-api	2.2.13-alt1_7jpp8	14	viy,@everybody
jetty	9.4.19-alt1_1.v20190610jpp8	14	viy,@everybody
jfsutils	1.1.15-alt3	15	mike,led,@qa,@everybody
kBuild	0.1.9998.r3178-alt4	14	sin,@qa
kannel	1.5.0-alt1.cvs20091101.3	15	week,@qa
koules	1.4-alt10	15	mike,@everybody
libblacs	1.1-alt15	15	darktemplar,@everybody
libchipmunk	7.0.3-alt1	14	george,@everybody
libdlna	0.2.4-alt2_12	16	viy,@everybody
libdmtx	0.7.5-alt1	16	george,@everybody
libgme	0.6.1-alt1	15	drool,@everybody
libiscsi	1.19.0-alt1	15	mike,@everybody
libkarma	0.1.2-alt1_12	16	viy,@everybody
liblbxutil	1.1.0-alt2	15	george,@everybody
libmonetra	7.14.0-alt1_1.1	16	viy,@everybody
libmp4v2-3	2.0-alt4	15	evg,@everybody
libmspub	0.1.4-alt1	15	shaba,@everybody
libnetcdff6-mpi	4.4.4-alt2	15	darktemplar,@everybody
libnetcdff6-seq	4.4.4-alt1	15	darktemplar,@everybody
libnut	0.0.675-alt1_10	16	viy,@everybody
libopennet	0.9.9-alt1_10	16	viy,@everybody
libqtelegram-ae	10.0.0-alt1	15	grenka
libreoffice-online	6.2.3.2-alt4	15	mvoronov,@everybody
libscalapack	1.8.0-alt20	15	darktemplar,@everybody
libsieve	2.2.5-alt1.qa2	15	enp,@qa
libta-lib	0.4.0-alt3	16	akv,@everybody
libxsettings-client0	0.17-alt2	16	viy,@everybody
liquidwar	5.6.4-alt6.1	15	george,@everybody
lmbench	3.0-alt3	14	antohami,@everybody
lterm	1.5.1-alt1	15	evg,@everybody
lzmalib	0.0.1-alt1_10	16	viy,@everybody
m4	1.4.18-alt2	17	@core
magicpoint	1.13a-alt4.20140908	15	rider,@everybody
mailx	8.1.2-alt7	15	@core
mars_nwe	0.99-alt5	14	mike,@everybody
mbm-gps-control	0.1.0-alt2	15	week,@everybody
mbrowse	0.4.3-alt3	15	oddity,@everybody
mcabber	1.0.5-alt1	15	mithraen,gns
mjpegtools	2.1.0-alt3	15	rider,@everybody
motion	4.1.1-alt3	15	ruslandh,@everybody
mtpaint	3.49.27-alt1	15	george,@qa
multipath-tools	0.8.3-alt2	15	shrek,mike,@everybody
mumps	4.10.0-alt11	15	darktemplar,@everybody
musl	1.1.3-alt2	16	led
nibbles	0.0.4-alt1.qa2	15	george,@qa
nvclock	0.8b4-alt5.qa1	15	mike,@qa,@everybody
ogdi	3.2.0-alt1.beta2.2	14	oddity,@everybody
open-iscsi	2.0.877-alt1.git73652184	15	snejok,@everybody
openal	1.19.1-alt1	15	shrek,@everybody
opennhrp	0.14.1-alt1	15	ender,@everybody
openrrcp	0.2.1-alt1	15	ender,@everybody
openscap	1.3.0-alt1	15	alexey,@everybody
ossec-hids	3.1.0-alt2	15	nickel,@everybody
owamp	3.5.0-alt2	15	imz,@everybody
pcc	1.0.0-alt2	15	oddity,@qa
pekwm	0.1.17-alt2	15	george,@everybody
perl-podlinkcheck	15-alt2	21	viy,@everybody
pesign	113-alt2	15	nickel,mike,@qa
pgadmin3	1.22.2-alt2	15	@pgsql,@qa,@everybody
phlipple	0.8.5-alt3	15	george,@everybody
pnetcdf	1.8.1-alt2.1	15	darktemplar,@everybody
ppp	2.4.8-alt2	14	mithraen,mike,shaba
prboom	2.5.0-alt0.3.1	15	oddity,@everybody
proxytoys	0:1.0-alt1_14jpp8	24	viy,@everybody
python-module-descartes	1.1.0-alt1.1	14	@python,@everybody
python-module-notify	0.1.1-alt6.1	15	@python
python3-module-babel	1:2.8.0-alt1	13	lav,@everybody
python3-module-croniter	0.3.34-alt1	22	@python,@everybody
python3-module-dateutil	2.8.1-alt2	22	lav,@python,@everybody
python3-module-djangorestframework	3.12.1-alt1	16	slev,@everybody
python3-module-js.jquery_joyride	1.0.3.1-alt2	19	@python,@everybody
python3-module-js.jquery_qtip	1.0.0-alt2	19	@python,@everybody
python3-module-oslo.versionedobjects	2.0.2-alt1	19	grenka,@python,@everybody
python3-module-oslo.vmware	3.4.0-alt1	19	grenka,@python,@everybody
python3-module-sphinxjp.themes.revealjs	0.3.0-alt3	20	@python,@everybody
qosmic	1.6.0-alt1	14	drool,@everybody
qt-fsarchiver	0.8.4.0-alt2	15	ruslandh,@everybody
qtiplot	0.9.8.9-alt9.svn20120124	20	vseleznv,@qa,@everybody
reaver	1.4-alt1	15	drool,@everybody
restbed	4.0-alt1_7	15	viy,@everybody
rezerwar	0.4.2-alt1	15	george,@everybody
roxterm	3.1.4-alt4	15	akv,@everybody
sbt	0.13.1-alt5_9.1jpp8	24	viy,@everybody
silver-searcher	2.2.0-alt2	15	vkni,@everybody
smstools	3.1.21-alt1	15	crux,@everybody
sniffit	0.3.7-alt4	15	george,@qa
snort	2.9.7.0-alt3	15	sem,oddity,timonbl4,@qa,@everybody
srecord	1.64-alt3	16	week,@everybody
stereograph	0.30a-alt2	15	dd,@everybody
stone_soup	0.21.1-alt1	15	george,@everybody
suspend-utils	1.0-alt1.git668c5f7	15	vseleznv,@qa
t4k_common	0.1.1-alt4.gita6c6b15	15	rider,viy,@everybody
telegramqml	2.0.0-alt2	15	ruslandh,@everybody
thinkfan	0.9.1-alt1	15	evg,@everybody
tinyfugue	5.0beta8-alt1	15	vkni,@everybody
uae	0.8.29-alt3	15	george,@everybody
udev-alsa	0.3-alt3	15	shrek,@everybody
unadf	0.7.12-alt1.qa1	16	george,@qa
unfs3	0.9.22-alt5	15	mike,@everybody
usbip	2.0.4-alt6	15	pv,led,@everybody
vice	3.4-alt2	15	mike,@qa,@everybody
vpn-ws	0.2-alt3	15	enp,@everybody
vzstat	7.0.25-alt1	19	shaba,@everybody
w3m	0.5.3-alt3.git20200502	18	eugvv,@qa,@everybody
weld-core	2.3.5-alt1_7jpp8	14	viy,@everybody
wf	0.41-alt1.qa1	15	evg,@everybody
wraplinux	1.7-alt1	15	ruslandh,@qa
xbean	0:4.14-alt1_1jpp8	14	viy,@everybody
xblast	2.10.4-alt1	15	george,@qa
xcrysden	1.5.60-alt1	15	lav,@everybody
xinetd	2.3.15-alt4	14	@core
xmedcon	0.16.2-alt1	16	rider,@everybody
xmr-stak	2.5.2-alt1	12	drool,@everybody
xorg-drv-amdgpu	19.1.0-alt1	15	george,@everybody
xtrkcad	4.0.3a-alt2	15	george,@qa,@everybody
xygrib	1.2.6-alt2	12	asy,@everybody
zabbix-module-sockets	1.1.0-alt4	15	evg,@everybody
zabbix-module-systemd	1.0.0-alt4	15	evg,@everybody
ziproxy	3.3.0-alt1	15	rt,@everybody

3. Список пакетов не на @nobody с ftbfs от 4 до 11 недель включительно на архитектуре x86_64:
$ awk '$3>=4 && $3<=11 && $4!="@nobody" {print}' beehive/stats/Sisyphus-x86_64/ftbfs-joined
SimGear	2020.1.2-alt4	9	mike,@qa,@everybody
desmume	0.9.11-alt3	4	oddity,@everybody
dict-mueller7-utf8	1.2-alt5	11	viy,@everybody
dict-web1913	1:1.4_0.47pd-alt2.1	11	mike,@qa
dino	0.2.0-alt1	4	aris
dreamchess	0.3.0-alt1.git5174b54	9	bip,@everybody
fsextender	0.1.5-alt1	5	evg,@everybody
glances	2.11.1-alt2	4	glebfm,@everybody
go-bindata	3.0.7-alt2_14.gita0ff256	5	viy,@everybody
golang-dep	0.5.0-alt2	5	darktemplar,@everybody
golang-github-burntsushi-toml-test	0.2.0-alt3.git39bb76d	5	slev,@everybody
golang-torproject-pluggable-transports-goptlib	0.7-alt1_2	5	viy,@everybody
hardening-wrapper	2.6-alt1	10	mike,@everybody
hyperscan	5.3.0-alt1	10	lav,@everybody
jitsi-meet	4109-alt0.2	4	lav,@everybody
kapacitor	1.5.3-alt1	5	shaba,@everybody
libmatheval	1.1.11-alt1_8	7	viy,@everybody
libmozjs78	78.0.1-alt2	4	aris
liri-materialdecoration	1.1.0-alt2	6	sbolshakov,@everybody
lxd3.0	3.0.4-alt1	5	shaba,@everybody
mdk	1.2.10-alt1	7	lav,@qa
micro	1.4.1-alt1	5	underwit,@everybody
origin-dockerregistry	3.11.0-alt1	5	shaba,@everybody
perl-Catalyst-Controller-HTML-FormFu	2.04-alt1_6	6	viy,@everybody
perl-HTML-FormFu-MultiForm	1.03-alt2	6	viy,@everybody
perl-SQL-Abstract-Limit	0.142-alt1	9	@cpan
python-module-argparse-manpage	1.1-alt1	4	slev,@everybody
python-module-ddt	1.1.1-alt1	4	snejok,@everybody
python-module-gitdb	2.0.3-alt3.qa1	4	darktemplar,@everybody
python3-module-apptools	4.5.0-alt1	4	lav,@everybody
python3-module-backcall	0.2.0-alt1	4	darktemplar,@everybody
python3-module-geojson	1.3.3-alt2	4	@python,@everybody
python3-module-gocept.loginuser	2.0-alt1	4	@python,@everybody
python3-module-http-checks	0.2.0-alt2	4	@python,@everybody
python3-module-natsort	7.0.1-alt1	4	@python,@everybody
python3-module-pyflakes	2.2.0-alt1	4	@python,@everybody
python3-module-pytest-benchmark	3.2.3-alt1	4	slev,@everybody
python3-module-requests_download	0.1.2-alt1	4	darktemplar,@everybody
python3-module-setuptools	1:46.1.3-alt2	4	slev,@python
python3-module-sphinx	1:2.4.4-alt1	4	darktemplar,@everybody
python3-module-sphinx-argparse	0.2.5-alt1	4	@python,@everybody
python3-module-sphinxcontrib_github_alt	1.2-alt1	4	darktemplar,@everybody
python3-module-testtools	2.3.0-alt3	4	lav,@everybody
python3-module-threadpoolctl	2.1.0-alt1	4	darktemplar,@everybody
python3-module-virtualenv-clone	0.5.4-alt1	4	nickf,@everybody
python3-module-waitress	1.2.1-alt3	4	@python,@everybody
python3-module-zope.exceptions	4.2.0-alt5	4	@python,@everybody
runv	1.0.0-alt1.git.cc051a6	5	shaba,@everybody
vmango	0.7.0-alt1	5	shaba,@everybody


-- 
ldv

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Dmitry V. Levin]

On Tue, Mar 30, 2021 at 05:23:47PM +0300, Dmitry V. Levin wrote:
[...]
> В результате регулярных обновлений тулчейна исправление ftbfs станет более
> равномерным и менее нервным процессом, а авральные исправления ftbfs перед
> бранчеванием уйдут в прошлое.

На всякий случай напомню очевидное: удаление несобирающегося пакета
является разновидностью исправления ftbfs.


-- 
ldv

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Anton Farygin]

On 30.03.2021 18:27, Dmitry V. Levin wrote:
> On Tue, Mar 30, 2021 at 05:23:47PM +0300, Dmitry V. Levin wrote:
> [...]
>> В результате регулярных обновлений тулчейна исправление ftbfs станет более
>> равномерным и менее нервным процессом, а авральные исправления ftbfs перед
>> бранчеванием уйдут в прошлое.
> На всякий случай напомню очевидное: удаление несобирающегося пакета
> является разновидностью исправления ftbfs.
>
>
Если под исправлением не подразумевается удаление, то это вообще 
отличный план, когда ftbfs будет чинить кто-то во всех возникших 
пакетах. Часто так и происходит.

Мне в целом идея очень нравится, т.к. обычно я добираюсь до исправления 
FTBFS уже тогда, когда поджимает ;(

Re: [devel] I: регулярные сборки =?utf-8?b?INGC0YPQu9GH0LXQudC90LA=?=, изменение в сопровождении пакетов

[Sergey Y. Afonin]

On Tuesday 30 March 2021, Anton Farygin wrote:

> Мне в целом идея очень нравится, т.к. обычно я добираюсь до исправления 
> FTBFS уже тогда, когда поджимает ;(
 
Иногда кажется, что апстрим уже вот-вот обновит версию. И это вот-вот
затягивается. А как только исправляешь FTBFS, сразу раз, и новая версия.
:-)

-- 
С уважением, Сергей Афонин

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Vladimir D. Seleznev]

On Tue, Mar 30, 2021 at 06:31:46PM +0300, Anton Farygin wrote:
> On 30.03.2021 18:27, Dmitry V. Levin wrote:
> > On Tue, Mar 30, 2021 at 05:23:47PM +0300, Dmitry V. Levin wrote:
> > [...]
> >> В результате регулярных обновлений тулчейна исправление ftbfs станет более
> >> равномерным и менее нервным процессом, а авральные исправления ftbfs перед
> >> бранчеванием уйдут в прошлое.
> > На всякий случай напомню очевидное: удаление несобирающегося пакета
> > является разновидностью исправления ftbfs.
> >
> >
> Если под исправлением не подразумевается удаление, то это вообще 
> отличный план, когда ftbfs будет чинить кто-то во всех возникших 
> пакетах. Часто так и происходит.

И всё-таки удаление пакета лучше формальной починки сборки, после
которой пакет неработоспособен. Один из самый ужасных опытов
использования ALT у пользователей — установка неработоспособных пакетов.

> Мне в целом идея очень нравится, т.к. обычно я добираюсь до исправления 
> FTBFS уже тогда, когда поджимает ;(

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Alexey V. Vissarionov]

On 2021-03-30 17:23:47 +0300, Dmitry V. Levin wrote:

 > gpm		1.20.1-alt18.1	15	@core

Выкинуть.

 > reaver	1.4-alt1	15	drool,@everybody

Выкинуть (есть замена в виде поддерживаемого reaver-t6x).


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Andrey Savchenko]

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

On Wed, 31 Mar 2021 13:55:18 +0300 Alexey V. Vissarionov wrote:
> On 2021-03-30 17:23:47 +0300, Dmitry V. Levin wrote:
> 
>  > gpm		1.20.1-alt18.1	15	@core
> 
> Выкинуть.

Я тебе выкину!

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Alexey V. Vissarionov]

On 2021-03-31 16:57:06 +0300, Andrey Savchenko wrote:

 >>> gpm		1.20.1-alt18.1	15	@core
 >> Выкинуть.
 > Я тебе выкину!

man screen


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Andrey Savchenko]

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

On Wed, 31 Mar 2021 17:29:31 +0300 Alexey V. Vissarionov wrote:
> On 2021-03-31 16:57:06 +0300, Andrey Savchenko wrote:
> 
>  >>> gpm		1.20.1-alt18.1	15	@core
>  >> Выкинуть.
>  > Я тебе выкину!
> 
> man screen

Слышал звон, да не знаешь где он? В консоли (не иксы) mousetrack
без gpm не будет работать. Кроме того, это не поможет в том же
elinks.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

[devel] FAILED del=gpm (Re: I: регулярные сборки =?utf-8?b?INGC0YPQu9GH0LXQudC90LA=?=, изменение в сопровождении =?utf-8?b?INC/0LDQutC10YLQvtCy?=)

[Sergey Y. Afonin]

On Wednesday 31 March 2021, Andrey Savchenko wrote:

> >  > gpm                1.20.1-alt18.1  15      @core
> > 
> > Выкинуть.
> 
> Я тебе выкину!
 
Ладно, а чинить кто будет? Список кандидатов большой. :-)

-- 
С уважением, Сергей Афонин

Re: [devel] FAILED del=gpm

[Alexey V. Vissarionov]

On 2021-04-17 12:22:10 +0400, Sergey Y. Afonin wrote:

 >>>> gpm                1.20.1-alt18.1  15      @core
 >>> Выкинуть.
 >> Я тебе выкину!
 > Ладно, а чинить кто будет? Список кандидатов большой. :-)

Да не надо его чинить... Для работы мышатины в xterm оно не
нужно, в консоли для копипасты существует screen, а экзотика
наподобие elinks бывает нужна пренебрежимо редко (и опять же
запускается чаще всего в xterm).

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] FAILED del=gpm

[Sergey V Turchin]

On Saturday, 17 April 2021 13:02:29 MSK Alexey V wrote:
> On 2021-04-17 12:22:10 +0400, Sergey Y. Afonin wrote:
>  >>>> gpm                1.20.1-alt18.1  15      @core
>  >>> 
>  >>> Выкинуть.
>  >> 
>  >> Я тебе выкину!
>  > 
>  > Ладно, а чинить кто будет? Список кандидатов большой. :-)
> 
> Да не надо его чинить... Для работы мышатины в xterm оно не
Для этого вообще linux не нужен. Можно с маздая сидеть и половину пакетов 
удалить.

> нужно, в консоли для копипасты существует screen
screen тебе на localhost! ;-)

[...]

-- 
Regards, Sergey.

Re: [devel] FAILED del=gpm

[Alexey V. Vissarionov]

On 2021-04-23 16:44:02 +0300, Sergey V Turchin wrote:

 >>>>>> gpm 1.20.1-alt18.1 15 @core
 >>>>> Выкинуть.
 >>>> Я тебе выкину!
 >>> Ладно, а чинить кто будет? Список кандидатов большой. :-)
 >> Да не надо его чинить... Для работы мышатины в xterm оно
 >> не нужно,
 > Для этого вообще linux не нужен. Можно с маздая сидеть и
 > половину пакетов удалить.

Мсье определенно знает толк... :-)

 >> в консоли для копипасты существует screen
 > screen тебе на localhost! ;-)

% ssh ::1 rpm -q screen | wc -l
1

Ну, есть он у меня тут... и что?
Даже работает. Прям щас.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] FAILED del=gpm (Re: I: регулярные сборки тулчейна в сопровождении =?utf-8?b?INC/0LDQutC10YLQvtCy?=)

[Andrey Savchenko]

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

On Sat, 17 Apr 2021 12:22:10 +0400 Sergey Y. Afonin wrote:
> On Wednesday 31 March 2021, Andrey Savchenko wrote:
> 
> > >  > gpm                1.20.1-alt18.1  15      @core
> > > 
> > > Выкинуть.
> > 
> > Я тебе выкину!
>  
> Ладно, а чинить кто будет? Список кандидатов большой. :-)
 
$ ssh build.alt acl sisyphus gpm show
gpm     @core

По-моему, очевидно: если люди закрыли пакет по ACL, то пусть сами
и чинят.

Вообще, нам нужна политика, что нельзя удалять FTBFS пакеты, если
они перед удалением меньше трёх месяцев были в @everybody.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] FAILED del=gpm (Re: I: регулярные сборки тулчейна в сопровождении =?utf-8?b?INC/0LDQutC10YLQvtCy?=)

[Vladimir D. Seleznev]

On Sat, Apr 17, 2021 at 03:59:29PM +0300, Andrey Savchenko wrote:
> On Sat, 17 Apr 2021 12:22:10 +0400 Sergey Y. Afonin wrote:
> > On Wednesday 31 March 2021, Andrey Savchenko wrote:
> > 
> > > >  > gpm                1.20.1-alt18.1  15      @core
> > > > 
> > > > Выкинуть.
> > > 
> > > Я тебе выкину!
> >  
> > Ладно, а чинить кто будет? Список кандидатов большой. :-)
>  
> $ ssh build.alt acl sisyphus gpm show
> gpm     @core
> 
> По-моему, очевидно: если люди закрыли пакет по ACL, то пусть сами
> и чинят.
> 
> Вообще, нам нужна политика, что нельзя удалять FTBFS пакеты, если
> они перед удалением меньше трёх месяцев были в @everybody.

Мысль хорошая, но вроде бы за некоторое время перед удаление пакет и так
переводится на @everybody.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Michael Shigorin]

On Tue, Mar 30, 2021 at 06:27:32PM +0300, Dmitry V. Levin wrote:
> На всякий случай напомню очевидное: удаление несобирающегося пакета
> является разновидностью исправления ftbfs.

Скорее обхода. :-)


On Tue, Mar 30, 2021 at 09:34:11PM +0400, Sergey Y. Afonin wrote:
> Иногда кажется, что апстрим уже вот-вот обновит версию.
> И это вот-вот затягивается. А как только исправляешь FTBFS,
> сразу раз, и новая версия.  :-)

Угу.


On Tue, Mar 30, 2021 at 05:23:47PM +0300, Dmitry V. Levin wrote:
> Для того, чтобы укладываться с исправлением всех ftbfs в 3 месяца,
> я предлагаю следующее изменение в сопровождении пакетов:
> - мантейнерам начинать исправлять ftbfs сразу, как только ftbfs возникают;

См. выше про апстримную работу -- тут варианты:
- или ты участвуешь в апстриме и там же исправляешь;
- или ты дублируешь работу апстрима (возможно, хуже);
- или ты сидишь и ждёшь, пока поправит тот, кому нужнее.

Разумеется, если вообще замечаешь эти письма счастья
(или натыкаешься самостоятельно).

> - сформировать группу мантейнеров, которая будет исправлять ftbfs в
>   пакетах других мантейнеров:
>   + для пакетов на @nobody - сразу, как только ftbfs возникают;
>   + для остальных пакетов - 4 недели спустя после возникновения ftbfs.

На всякий: конкретно в моих пакетах исправляйте на здоровье,
последние несколько лет я по факту принимаю мало участия в сизифе
по той простой причине, что большая часть внимания уходит на
sisyphus_e2k и соответствующие бранчи.

> 1. Список пакетов на @nobody с ftbfs на архитектуре x86_64:
> $ awk '$4=="@nobody" {print}' beehive/stats/Sisyphus-x86_64/ftbfs-joined

> ltspfs	0.3-alt4.20070117.qa1	14	@nobody
> ltspfsd	0.3-alt0.2.2.qa1	14	@nobody

Удалил, т.к. LTSP если поднимать заново, то системно
(отвалилось там уже много).  Насколько понимаю,
развалились с переменами в заголовках glibc (RPC).

> p3nfs	5.19-alt1.qa2	14	@nobody
> unfs3	0.9.22-alt5	15	mike,@everybody // из другого списка

Возможно, такие пакеты стоит выделить и пройти по ним одними
руками (либо группой рук) -- каждому отдельному майнтейнеру
разбираться в том, что именно надо предпринять (добавить в BR),
и делать -- будет заведомо менее эффективно, чем один раз
разобраться, изложить рецепт и внедрить его (возможно, лучше
даже viy@ бы попросить конкретно по жертвам переезда RPC
пройтись роботом, если вопрос именно в BR).

> xd3d	8.3.1-alt5	15	@nobody

Фортран...

> 2. Список пакетов не на @nobody с ftbfs от 12 недель на архитектуре x86_64:
> $ awk '$3>=12 && $4!="@nobody" {print}' beehive/stats/Sisyphus-x86_64/ftbfs-joined
> CBFlib	0.9.2.3-alt2	15	mike,@everybody

Тоже фортран.

> chestnut-dialer	0.3.3-alt8.3	17	mike,darktemplar,@qa

Похоронил с почестями (texinfo-документация не собирается).

> gpm	1.20.1-alt18.1	15	@core
> gwc	0.21.17-alt2	15	mike,@everybody
> hp2xx	3.4.2-alt1	15	mike,@everybody
> jfsutils	1.1.15-alt3	15	mike,led,@qa,@everybody
> koules	1.4-alt10	15	mike,@everybody
> libiscsi	1.19.0-alt1	15	mike,@everybody
> udev-alsa	0.3-alt3	15	shrek,@everybody
> vice	3.4-alt2	15	mike,@qa,@everybody

А что это за многочисленные "multiple definition" на линковке?

> mars_nwe	0.99-alt5	14	mike,@everybody
> nvclock	0.8b4-alt5.qa1	15	mike,@qa,@everybody

Можно и удалить...

> ppp	2.4.8-alt2	14	mithraen,mike,shaba

Здесь явно при делах обновление dhcpcd -- sem@, глянешь?

dhcpc.c: In function 'change_mode':
dhcpc.c:147:51: error: 'sys_errlist' undeclared (first use in this function)
  147 |     fatal("DHCPC: couldn't listen on socket, %s", sys_errlist[errno]);
      |                                                   ^~~~~~~~~~~
dhcpc.c:147:51: note: each undeclared identifier is reported only once for each function it appears in
dhcpc.c: In function 'dhcp_rx':
dhcpc.c:211:60: error: 'sys_errlist' undeclared (first use in this function)
  211 |       dbglog("DHCPC: error on read, %s, reopening socket", sys_errlist[errno]);
      |                                                            ^~~~~~~~~~~
dhcpc.c: In function 'dhcp_request_new':
dhcpc.c:383:55: error: 'sys_errlist' undeclared (first use in this function)
  383 |  dbglog("DHCPC: error on read, %s, reopening socket", sys_errlist[errno]);
      |                                                       ^~~~~~~~~~~
make[2]: *** [Makefile:30: dhcpc.lo] Error 1
make[2]: Leaving directory '/usr/src/RPM/BUILD/ppp-2.4.8/pppd/plugins/dhcp'
make[1]: *** [Makefile:35: all] Error 2
make[1]: Leaving directory '/usr/src/RPM/BUILD/ppp-2.4.8/pppd/plugins'
make: *** [Makefile:16: all] Error 2

> 3. Список пакетов не на @nobody с ftbfs от 4 до 11 недель включительно на архитектуре x86_64:
> $ awk '$3>=4 && $3<=11 && $4!="@nobody" {print}' beehive/stats/Sisyphus-x86_64/ftbfs-joined
> SimGear	2020.1.2-alt4	9	mike,@qa,@everybody

Сломался с новым бюстом; отправил FG 2020.3.8: #268722.

> dict-web1913	1:1.4_0.47pd-alt2.1	11	mike,@qa

Гм, а этот пакет стоит применять для тестирования buildreq --
в текущем сизифе там в BuildRequires: значилась libltdl, помимо
других странностей, а на текущем состоянии ОС на сервере basalt
получилась вот такая химера:

# Automatically added by buildreq on Wed Mar 31 2021
# optimized out: gem-power-assert glibc-kernheaders-generic glibc-kernheaders-x86 gnu-config perl python-base python-modules python3-base ruby ruby-addressable ruby-coderay ruby-cookiejar ruby-em-socksify ruby-eventmachine ruby-faraday ruby-http_parser.rb ruby-method_source ruby-mime-types-data ruby-multipart-post ruby-pry ruby-public_suffix ruby-rake ruby-rdoc ruby-sawyer ruby-stdlibs sh4
BuildRequires: flex gem-did-you-mean gem-setup pesign python3 ruby-bundler ruby-em-http-request ruby-em-synchrony ruby-mime-types ruby-minitest ruby-msgpack ruby-multi_json ruby-net-telnet ruby-netrc ruby-octokit.rb ruby-oj ruby-rubygems-update ruby-simple_oauth ruby-test-unit ruby-xmlrpc yajl-ruby

При этом реально нужно только:

BuildRequires: dict-tools flex

Отправил исправленный пакет.

> hardening-wrapper	2.6-alt1	10	mike,@everybody

Удалил -- похоже, у нас оно так никому и не понадобилось.

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

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Anton Farygin]

On 31.03.2021 16:06, Michael Shigorin wrote:
> А что это за многочисленные "multiple definition" на линковке?

Копать в сторону extern

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Mikhail Novosyolov]

31.03.2021 16:06, Michael Shigorin пишет:
>> gpm	1.20.1-alt18.1	15	@core
>> gwc	0.21.17-alt2	15	mike,@everybody
>> hp2xx	3.4.2-alt1	15	mike,@everybody
>> jfsutils	1.1.15-alt3	15	mike,led,@qa,@everybody
>> koules	1.4-alt10	15	mike,@everybody
>> libiscsi	1.19.0-alt1	15	mike,@everybody
>> udev-alsa	0.3-alt3	15	shrek,@everybody
>> vice	3.4-alt2	15	mike,@qa,@everybody
> А что это за многочисленные "multiple definition" на линковке?
-fcommon по умолчанию в новом gcc, объезжается костылем -fno-common

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Alexey V. Vissarionov]

On 2021-03-31 18:47:54 +0300, Mikhail Novosyolov wrote:

 >> А что это за многочисленные "multiple definition" на линковке?
 > -fcommon по умолчанию в новом gcc, объезжается костылем -fno-common

Только в код перед этим неплохо было бы все же посмотреть...


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Grigory Ustinov]

31.03.2021 18:47, Mikhail Novosyolov пишет:
> 31.03.2021 16:06, Michael Shigorin пишет:
>>> gpm	1.20.1-alt18.1	15	@core
>>> gwc	0.21.17-alt2	15	mike,@everybody
>>> hp2xx	3.4.2-alt1	15	mike,@everybody
>>> jfsutils	1.1.15-alt3	15	mike,led,@qa,@everybody
>>> koules	1.4-alt10	15	mike,@everybody
>>> libiscsi	1.19.0-alt1	15	mike,@everybody
>>> udev-alsa	0.3-alt3	15	shrek,@everybody
>>> vice	3.4-alt2	15	mike,@qa,@everybody
>> А что это за многочисленные "multiple definition" на линковке?
> -fcommon по умолчанию в новом gcc, объезжается костылем -fno-common
Только абсолютно наоборот.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Dmitry V. Levin]

On Wed, Mar 31, 2021 at 04:06:26PM +0300, Michael Shigorin wrote:
[...]
> > gpm	1.20.1-alt18.1	15	@core
> > gwc	0.21.17-alt2	15	mike,@everybody
> > hp2xx	3.4.2-alt1	15	mike,@everybody
> > jfsutils	1.1.15-alt3	15	mike,led,@qa,@everybody
> > koules	1.4-alt10	15	mike,@everybody
> > libiscsi	1.19.0-alt1	15	mike,@everybody
> > udev-alsa	0.3-alt3	15	shrek,@everybody
> > vice	3.4-alt2	15	mike,@qa,@everybody
> 
> А что это за многочисленные "multiple definition" на линковке?

https://lists.altlinux.org/pipermail/devel/2020-December/212848.html

[...]
> > ppp	2.4.8-alt2	14	mithraen,mike,shaba
> 
> Здесь явно при делах обновление dhcpcd -- sem@, глянешь?
> 
> dhcpc.c: In function 'change_mode':
> dhcpc.c:147:51: error: 'sys_errlist' undeclared (first use in this function)
>   147 |     fatal("DHCPC: couldn't listen on socket, %s", sys_errlist[errno]);
>       |                                                   ^~~~~~~~~~~
> dhcpc.c:147:51: note: each undeclared identifier is reported only once for each function it appears in
> dhcpc.c: In function 'dhcp_rx':
> dhcpc.c:211:60: error: 'sys_errlist' undeclared (first use in this function)
>   211 |       dbglog("DHCPC: error on read, %s, reopening socket", sys_errlist[errno]);
>       |                                                            ^~~~~~~~~~~
> dhcpc.c: In function 'dhcp_request_new':
> dhcpc.c:383:55: error: 'sys_errlist' undeclared (first use in this function)
>   383 |  dbglog("DHCPC: error on read, %s, reopening socket", sys_errlist[errno]);
>       |                                                       ^~~~~~~~~~~
> make[2]: *** [Makefile:30: dhcpc.lo] Error 1
> make[2]: Leaving directory '/usr/src/RPM/BUILD/ppp-2.4.8/pppd/plugins/dhcp'
> make[1]: *** [Makefile:35: all] Error 2
> make[1]: Leaving directory '/usr/src/RPM/BUILD/ppp-2.4.8/pppd/plugins'
> make: *** [Makefile:16: all] Error 2

Это не про dhcpcd, см. ppp в
https://lists.altlinux.org/pipermail/devel/2020-December/213130.html

> # Automatically added by buildreq on Wed Mar 31 2021
> # optimized out: gem-power-assert glibc-kernheaders-generic glibc-kernheaders-x86 gnu-config perl python-base python-modules python3-base ruby ruby-addressable ruby-coderay ruby-cookiejar ruby-em-socksify ruby-eventmachine ruby-faraday ruby-http_parser.rb ruby-method_source ruby-mime-types-data ruby-multipart-post ruby-pry ruby-public_suffix ruby-rake ruby-rdoc ruby-sawyer ruby-stdlibs sh4
> BuildRequires: flex gem-did-you-mean gem-setup pesign python3 ruby-bundler ruby-em-http-request ruby-em-synchrony ruby-mime-types ruby-minitest ruby-msgpack ruby-multi_json ruby-net-telnet ruby-netrc ruby-octokit.rb ruby-oj ruby-rubygems-update ruby-simple_oauth ruby-test-unit ruby-xmlrpc yajl-ruby
> 
> При этом реально нужно только:
> 
> BuildRequires: dict-tools flex

Какие у вас в ruby крутые циклы, однако.


-- 
ldv

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Dmitry V. Levin]

On Tue, Mar 30, 2021 at 05:23:47PM +0300, Dmitry V. Levin wrote:
[...]
> Для того, чтобы укладываться с исправлением всех ftbfs в 3 месяца,
> я предлагаю следующее изменение в сопровождении пакетов:
> - мантейнерам начинать исправлять ftbfs сразу, как только ftbfs возникают;
> - сформировать группу мантейнеров, которая будет исправлять ftbfs в
>   пакетах других мантейнеров:
>   + для пакетов на @nobody - сразу, как только ftbfs возникают;
>   + для остальных пакетов - 4 недели спустя после возникновения ftbfs.

Поскольку возражений не поступило, будем считать, что все согласны
с этим предложением. :)


-- 
ldv

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Anton Farygin]

On 04.04.2021 21:49, Dmitry V. Levin wrote:
> On Tue, Mar 30, 2021 at 05:23:47PM +0300, Dmitry V. Levin wrote:
> [...]
>> Для того, чтобы укладываться с исправлением всех ftbfs в 3 месяца,
>> я предлагаю следующее изменение в сопровождении пакетов:
>> - мантейнерам начинать исправлять ftbfs сразу, как только ftbfs возникают;
>> - сформировать группу мантейнеров, которая будет исправлять ftbfs в
>>    пакетах других мантейнеров:
>>    + для пакетов на @nobody - сразу, как только ftbfs возникают;
>>    + для остальных пакетов - 4 недели спустя после возникновения ftbfs.
> Поскольку возражений не поступило, будем считать, что все согласны
> с этим предложением. :)
>
>
А чем это будет отличаться от текущей ситуации ,

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Dmitry V. Levin]

On Sun, Apr 04, 2021 at 10:15:00PM +0300, Anton Farygin wrote:
> On 04.04.2021 21:49, Dmitry V. Levin wrote:
> > On Tue, Mar 30, 2021 at 05:23:47PM +0300, Dmitry V. Levin wrote:
> > [...]
> >> Для того, чтобы укладываться с исправлением всех ftbfs в 3 месяца,
> >> я предлагаю следующее изменение в сопровождении пакетов:
> >> - мантейнерам начинать исправлять ftbfs сразу, как только ftbfs возникают;
> >> - сформировать группу мантейнеров, которая будет исправлять ftbfs в
> >>    пакетах других мантейнеров:
> >>    + для пакетов на @nobody - сразу, как только ftbfs возникают;
> >>    + для остальных пакетов - 4 недели спустя после возникновения ftbfs.
> > Поскольку возражений не поступило, будем считать, что все согласны
> > с этим предложением. :)
> >
> А чем это будет отличаться от текущей ситуации ,

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

Насколько я помню, группа @qa когда-то была создана для этих целей,
но со временем переродилась.

Можно создать группу с другим именем, если понадобится.


-- 
ldv

[devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Michael Shigorin]

On Sun, Apr 04, 2021 at 11:16:05PM +0300, Dmitry V. Levin wrote:
> > > Поскольку возражений не поступило, будем считать,
> > > что все согласны с этим предложением. :)
> > А чем это будет отличаться от текущей ситуации ,
> - мантейнеры не будут откладывать исправление на полгода,
>   потому что уже через месяц их пакеты начнут удаляться;
> - мы сформируем группу добровольцев, которые начнут исправлять
>   ftbfs в пакетах других мантейнеров.

Первое не означает _исправления_ пакетов, как ты мог и сам
догадаться; второе требует существенного личного вклада примером
(и, возможно, координацией), поскольку задача муторная.

Вообще мне кажется, что баланс интересов по первому стоит
как-то более внятно озвучить: зачем именно майнтейнерам
напрягаться сильнее-чаще-быстрее?

> Насколько я помню, группа @qa когда-то была создана для этих
> целей, но со временем переродилась.  Можно создать группу
> с другим именем, если понадобится.

Или почистить @qa (например, от меня по факту).

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

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Michael Shigorin]

On Sun, Apr 04, 2021 at 11:30:59PM +0300, Aleksey Novodvorsky wrote:
> > > > > Поскольку возражений не поступило, будем считать,
> > > > > что все согласны с этим предложением. :)
> > > > А чем это будет отличаться от текущей ситуации ,
> > > - мантейнеры не будут откладывать исправление на полгода,
> > >   потому что уже через месяц их пакеты начнут удаляться;
> > Вообще мне кажется, что баланс интересов по первому стоит
> > как-то более внятно озвучить: зачем именно майнтейнерам
> > напрягаться сильнее-чаще-быстрее?
> Интересы у каждого свои и я не думаю, что тут стоит их
> обсуждать.  Мейнтейнеры же взяли эти пакеты на себя и,
> наверное, заинтересованы в их работоспособности.

Да, просто когда договорённости с берега меняются
в процессе (пусть и межгалактического перелёта) --
лучше это обозначать, чем потом удивляться.

Например, блицкриг "все на gear" аккурат в годы подъёма
убунты обошёлся команде весьма дорого.

> > > Насколько я помню, группа @qa когда-то была создана для
> > > этих целей, но со временем переродилась.  Можно создать
> > > группу с другим именем, если понадобится.
> > Или почистить @qa (например, от меня по факту).
> Я понимаю, что проект Эльбрус стоит, к сожалению, особняком,
> в том числе по ряду внешних причин. Но все же вряд ли стоит его
> обособлять ещё больше по своей инициативе.

Тут дело не в "особняке", а в приоритетах -- я по факту
потихоньку начинаю забывать про x86. :-)

Соответственно если от меня ожидается реакция именно по линии @qa
-- обычно она сводится максимум к "посмотрел-одобрил", хотя порой
всё-таки ещё и чиню что-то (что тоже по-своему вдохновляет,
просто случается раз-другой в год, наверное).

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

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Dmitry V. Levin]

On Mon, Apr 05, 2021 at 12:50:11AM +0300, Aleksey Novodvorsky wrote:
> пн, 5 апр. 2021 г., 00:36 Michael Shigorin <mike@altlinux.org>:
> > On Sun, Apr 04, 2021 at 11:30:59PM +0300, Aleksey Novodvorsky wrote:
> > > > > > > Поскольку возражений не поступило, будем считать,
> > > > > > > что все согласны с этим предложением. :)
> > > > > > А чем это будет отличаться от текущей ситуации ,
> > > > > - мантейнеры не будут откладывать исправление на полгода,
> > > > >   потому что уже через месяц их пакеты начнут удаляться;
> > > > Вообще мне кажется, что баланс интересов по первому стоит
> > > > как-то более внятно озвучить: зачем именно майнтейнерам
> > > > напрягаться сильнее-чаще-быстрее?
> > > Интересы у каждого свои и я не думаю, что тут стоит их
> > > обсуждать.  Мейнтейнеры же взяли эти пакеты на себя и,
> > > наверное, заинтересованы в их работоспособности.
> >
> > Да, просто когда договорённости с берега меняются
> > в процессе (пусть и межгалактического перелёта) --
> > лучше это обозначать, чем потом удивляться.
> 
> Дима напомнил об известной проблеме и предложил решение.
> Вы не знали о проблеме или у Вас есть  иное предложение о её решении?
> К сожалению, рассылки извещений не работают.

Техническое замечание: рассылки извещений по-прежнему работают, но,
как мы видим, результат неудовлетворительный, т.е. одних рассылок
извещений, очевидно, недостаточно.

Поэтому, исходя из предположений, которые я озвучил,
было сформулировано это предложение.


-- 
ldv

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Andrey Savchenko]

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

On Mon, 5 Apr 2021 00:50:11 +0300 Aleksey Novodvorsky wrote:
> пн, 5 апр. 2021 г., 00:36 Michael Shigorin <mike@altlinux.org>:
> 
> > On Sun, Apr 04, 2021 at 11:30:59PM +0300, Aleksey Novodvorsky wrote:
> > > > > > > Поскольку возражений не поступило, будем считать,
> > > > > > > что все согласны с этим предложением. :)
> > > > > > А чем это будет отличаться от текущей ситуации ,
> > > > > - мантейнеры не будут откладывать исправление на полгода,
> > > > >   потому что уже через месяц их пакеты начнут удаляться;

^^^
ниже про вот это

> > > > Вообще мне кажется, что баланс интересов по первому стоит
> > > > как-то более внятно озвучить: зачем именно майнтейнерам
> > > > напрягаться сильнее-чаще-быстрее?
> > > Интересы у каждого свои и я не думаю, что тут стоит их
> > > обсуждать.  Мейнтейнеры же взяли эти пакеты на себя и,
> > > наверное, заинтересованы в их работоспособности.
> >
> > Да, просто когда договорённости с берега меняются
> > в процессе (пусть и межгалактического перелёта) --
> > лучше это обозначать, чем потом удивляться.
> >
> 
> Дима напомнил об известной проблеме и предложил решение.
> Вы не знали о проблеме или у Вас есть  иное предложение о её решении?
> К сожалению, рассылки извещений не работают.
> 
> 
> > Например, блицкриг "все на gear" аккурат в годы подъёма
> > убунты обошёлся команде весьма дорого.
> >
> Вам есть что сказать о возможном решении проблемы ftbfs или Вы просто
> хотите увести обсуждение в сторону?

Мне — есть. Предлагаемый период месяц слишком мал, т.к. мейнтенер
может уйти на месяц в отпуск (не зависимо от того где он
работает), а в отпуске человек имеет право отдыхать, а не бросать
всё потому что иначе удалят его пакеты. 

Поэтому FTBFS TTL < 3m считаю неоправданным.

Ещё вопрос: как быть с мигающими пакетами, у которые иногда
попадают в FTBFS, затем исчезают? Проблема не праздная, т.к. у нас
есть нерешённая проблема пересборочницы, которая время от времени
выявляет проблемы, которые невозможно воспроизвести на штатной
сборочнице, а отладочного доступа к пересборочнице у простых
разработчиков нет.

Я предлагаю отсчитывать FTBFS TTL с момента последней успешной
пересборки.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Dmitry V. Levin]

On Mon, Apr 05, 2021 at 01:05:59AM +0300, Andrey Savchenko wrote:
[...]
> Мне — есть. Предлагаемый период месяц слишком мал, т.к. мейнтенер
> может уйти на месяц в отпуск (не зависимо от того где он
> работает), а в отпуске человек имеет право отдыхать, а не бросать
> всё потому что иначе удалят его пакеты. 
> 
> Поэтому FTBFS TTL < 3m считаю неоправданным.

3 месяца - это срок, за который все FTBFS так или иначе должны устранятся.
Если за месяц мантейнер не нашёл возможности исправить FTBFS,
значит, либо мантейнеру нужна помощь, либо пакет с FTBFS не актуален.
И в том, и в другом случае потребуется время, чтобы пакет исправить
или удалить.  Давайте уточним сроки.

> Ещё вопрос: как быть с мигающими пакетами, у которые иногда
> попадают в FTBFS, затем исчезают? Проблема не праздная, т.к. у нас
> есть нерешённая проблема пересборочницы, которая время от времени
> выявляет проблемы, которые невозможно воспроизвести на штатной
> сборочнице, а отладочного доступа к пересборочнице у простых
> разработчиков нет.

Я не люблю такие FTBFS, которые появляются и исчезают по несколько
раз в неделю, это создаёт информационный шум.  Однако ...

> Я предлагаю отсчитывать FTBFS TTL с момента последней успешной
> пересборки.

... именно так оно и отсчитывается.


-- 
ldv

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Anton Farygin]

On 05.04.2021 01:19, Dmitry V. Levin wrote:
> On Mon, Apr 05, 2021 at 01:05:59AM +0300, Andrey Savchenko wrote:
> [...]
>> Мне — есть. Предлагаемый период месяц слишком мал, т.к. мейнтенер
>> может уйти на месяц в отпуск (не зависимо от того где он
>> работает), а в отпуске человек имеет право отдыхать, а не бросать
>> всё потому что иначе удалят его пакеты.
>>
>> Поэтому FTBFS TTL < 3m считаю неоправданным.
> 3 месяца - это срок, за который все FTBFS так или иначе должны устранятся.
> Если за месяц мантейнер не нашёл возможности исправить FTBFS,
> значит, либо мантейнеру нужна помощь, либо пакет с FTBFS не актуален.
> И в том, и в другом случае потребуется время, чтобы пакет исправить
> или удалить.  Давайте уточним сроки.

Если ввести запрет на удаление пакета в рамках удаления FTBFS, то срок 
для _исправления_ пакета в 1 неделю выглядит хорошо.

А у нас уже нет пакетов, которые собираются на сборочнице но не 
пересобираются в beehive ?

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Dmitry V. Levin]

On Mon, Apr 05, 2021 at 08:10:18AM +0300, Anton Farygin wrote:
[...]
> А у нас уже нет пакетов, которые собираются на сборочнице но не 
> пересобираются в beehive ?

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


-- 
ldv

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Anton Farygin]

On 05.04.2021 13:43, Dmitry V. Levin wrote:
> On Mon, Apr 05, 2021 at 08:10:18AM +0300, Anton Farygin wrote:
> [...]
>> А у нас уже нет пакетов, которые собираются на сборочнице но не
>> пересобираются в beehive ?
> Не считая флуктуаций (которые будут и на сборочнице проявляться,
> наверное, если собирать ежедневно), насколько мне известно, нет.
>
>
Отличная новость. Спасибо.

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Grigory Ustinov]

05.04.2021 1:05, Andrey Savchenko пишет:
> On Mon, 5 Apr 2021 00:50:11 +0300 Aleksey Novodvorsky wrote:
>> пн, 5 апр. 2021 г., 00:36 Michael Shigorin <mike@altlinux.org>:
>>
>>> On Sun, Apr 04, 2021 at 11:30:59PM +0300, Aleksey Novodvorsky wrote:
>>>>>>>> Поскольку возражений не поступило, будем считать,
>>>>>>>> что все согласны с этим предложением. :)

Я вот не возражал, потому что думал, что это какая-то первоапрельская 
шутка. Уж слишком утопично это всё. Давайте мир во всём мире и всё в 
таком духе.

>>>>>>> А чем это будет отличаться от текущей ситуации ,
>>>>>> - мантейнеры не будут откладывать исправление на полгода,
>>>>>>    потому что уже через месяц их пакеты начнут удаляться;

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

Лично моё мнение, что удаление ftbfs через месяц приведёт к огромному 
количеству проблем, начиная с мощного уменьшения пакетной базы и 
заканчивая уменьшением количества мейнтейнеров из коммьюнити.

>>>>> Вообще мне кажется, что баланс интересов по первому стоит
>>>>> как-то более внятно озвучить: зачем именно майнтейнерам
>>>>> напрягаться сильнее-чаще-быстрее?
>>>> Интересы у каждого свои и я не думаю, что тут стоит их
>>>> обсуждать.  Мейнтейнеры же взяли эти пакеты на себя и,
>>>> наверное, заинтересованы в их работоспособности.
>>> Да, просто когда договорённости с берега меняются
>>> в процессе (пусть и межгалактического перелёта) --
>>> лучше это обозначать, чем потом удивляться.
>>>
>> Дима напомнил об известной проблеме и предложил решение.
>> Вы не знали о проблеме или у Вас есть  иное предложение о её решении?
>> К сожалению, рассылки извещений не работают.
>>
>>
>>> Например, блицкриг "все на gear" аккурат в годы подъёма
>>> убунты обошёлся команде весьма дорого.
>>>
>> Вам есть что сказать о возможном решении проблемы ftbfs или Вы просто
>> хотите увести обсуждение в сторону?
> Мне — есть. Предлагаемый период месяц слишком мал, т.к. мейнтенер
> может уйти на месяц в отпуск (не зависимо от того где он
> работает), а в отпуске человек имеет право отдыхать, а не бросать
> всё потому что иначе удалят его пакеты.

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


Принудительная форма решения этой проблемы породит просто новые способы 
её обхода. Как я уже однажды заметил, не обязательно чинить пакет, от 
которого зависит какой-то другой пакет, потому что его точно не удалят. 
Не обязательно чинить общеупотребимые пакеты типа браузеров, потому что 
их тоже не удалят.

Мне больше нравится добровольная форма решения, предложенная когда-то 
mike@. Устраивать что-то вроде субботников каждый месяц, когда люди 
могут собраться и абстрагировавшись от всего заняться исправлением ftbfs.

Кроме всего прочего, человек может просто элементарно не знать, как 
починить пакет. На озвученном выше мероприятии, коллеги могут ему чем-то 
помочь.

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Grigory Ustinov]

05.04.2021 8:23, Grigory Ustinov пишет:
> 05.04.2021 1:05, Andrey Savchenko пишет:
>> On Mon, 5 Apr 2021 00:50:11 +0300 Aleksey Novodvorsky wrote:
>>> пн, 5 апр. 2021 г., 00:36 Michael Shigorin <mike@altlinux.org>:
>>>
>>>> On Sun, Apr 04, 2021 at 11:30:59PM +0300, Aleksey Novodvorsky wrote:
>>>>>>>>> Поскольку возражений не поступило, будем считать,
>>>>>>>>> что все согласны с этим предложением. :)
>
> Я вот не возражал, потому что думал, что это какая-то первоапрельская 
> шутка. Уж слишком утопично это всё. Давайте мир во всём мире и всё в 
> таком духе.
>
>>>>>>>> А чем это будет отличаться от текущей ситуации ,
>>>>>>> - мантейнеры не будут откладывать исправление на полгода,
>>>>>>>    потому что уже через месяц их пакеты начнут удаляться;
>
> Мейнтейнеров много хороших и разных. Некоторые поддерживают десяток 
> пакетов, некоторые сотню, а некоторые тысячу, а срок исправления для 
> всех одинаковый. Есть у нас и такие мейнтейнеры, которые в текстовом 
> файле есть, а по факту их нет.
>
> Лично моё мнение, что удаление ftbfs через месяц приведёт к огромному 
> количеству проблем, начиная с мощного уменьшения пакетной базы и 
> заканчивая уменьшением количества мейнтейнеров из коммьюнити.
>
>>>>>> Вообще мне кажется, что баланс интересов по первому стоит
>>>>>> как-то более внятно озвучить: зачем именно майнтейнерам
>>>>>> напрягаться сильнее-чаще-быстрее?
>>>>> Интересы у каждого свои и я не думаю, что тут стоит их
>>>>> обсуждать.  Мейнтейнеры же взяли эти пакеты на себя и,
>>>>> наверное, заинтересованы в их работоспособности.
>>>> Да, просто когда договорённости с берега меняются
>>>> в процессе (пусть и межгалактического перелёта) --
>>>> лучше это обозначать, чем потом удивляться.
>>>>
>>> Дима напомнил об известной проблеме и предложил решение.
>>> Вы не знали о проблеме или у Вас есть  иное предложение о её решении?
>>> К сожалению, рассылки извещений не работают.
>>>
>>>
>>>> Например, блицкриг "все на gear" аккурат в годы подъёма
>>>> убунты обошёлся команде весьма дорого.
>>>>
>>> Вам есть что сказать о возможном решении проблемы ftbfs или Вы просто
>>> хотите увести обсуждение в сторону?
P.S. Чтобы увести разговор в сторону, хочу заметить, что есть ещё 
проблема багзиллы и там даже есть какие-то статусы ошибок, по правилам, 
требующие исправления в указанный срок. Можно было бы делать отдельные 
субботники с исправлением багов.
>> Мне — есть. Предлагаемый период месяц слишком мал, т.к. мейнтенер
>> может уйти на месяц в отпуск (не зависимо от того где он
>> работает), а в отпуске человек имеет право отдыхать, а не бросать
>> всё потому что иначе удалят его пакеты.
>
> Не говоря уже о том, что у людей бывает работа и ему надо всё бросить 
> и идти чинить свою гору пакетов.
>
>
> Принудительная форма решения этой проблемы породит просто новые 
> способы её обхода. Как я уже однажды заметил, не обязательно чинить 
> пакет, от которого зависит какой-то другой пакет, потому что его точно 
> не удалят. Не обязательно чинить общеупотребимые пакеты типа 
> браузеров, потому что их тоже не удалят.
>
> Мне больше нравится добровольная форма решения, предложенная когда-то 
> mike@. Устраивать что-то вроде субботников каждый месяц, когда люди 
> могут собраться и абстрагировавшись от всего заняться исправлением ftbfs.
>
> Кроме всего прочего, человек может просто элементарно не знать, как 
> починить пакет. На озвученном выше мероприятии, коллеги могут ему 
> чем-то помочь.
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Andrey Cherepanov]

05.04.2021 08:23, Grigory Ustinov пишет:
> 05.04.2021 1:05, Andrey Savchenko пишет:
>> On Mon, 5 Apr 2021 00:50:11 +0300 Aleksey Novodvorsky wrote:
>>> пн, 5 апр. 2021 г., 00:36 Michael Shigorin <mike@altlinux.org>:
>>>
>>>> On Sun, Apr 04, 2021 at 11:30:59PM +0300, Aleksey Novodvorsky wrote:
>>>>>>>>> Поскольку возражений не поступило, будем считать,
>>>>>>>>> что все согласны с этим предложением. :)
>
> Я вот не возражал, потому что думал, что это какая-то первоапрельская 
> шутка. Уж слишком утопично это всё. Давайте мир во всём мире и всё в 
> таком духе.
>
>>>>>>>> А чем это будет отличаться от текущей ситуации ,
>>>>>>> - мантейнеры не будут откладывать исправление на полгода,
>>>>>>>    потому что уже через месяц их пакеты начнут удаляться;
>
> Мейнтейнеров много хороших и разных. Некоторые поддерживают десяток 
> пакетов, некоторые сотню, а некоторые тысячу, а срок исправления для 
> всех одинаковый. Есть у нас и такие мейнтейнеры, которые в текстовом 
> файле есть, а по факту их нет.
>
> Лично моё мнение, что удаление ftbfs через месяц приведёт к огромному 
> количеству проблем, начиная с мощного уменьшения пакетной базы и 
> заканчивая уменьшением количества мейнтейнеров из коммьюнити.

Даже если все пакеты из FTBFS будут удалены, не порождая анметов, это не 
превысит 1%.

Социальная сторона также некритична: если мейнтейнер не чинил пакет, то 
и реакции на удаление вряд ли стоит ждать.

>
>>>>>> Вообще мне кажется, что баланс интересов по первому стоит
>>>>>> как-то более внятно озвучить: зачем именно майнтейнерам
>>>>>> напрягаться сильнее-чаще-быстрее?
>>>>> Интересы у каждого свои и я не думаю, что тут стоит их
>>>>> обсуждать.  Мейнтейнеры же взяли эти пакеты на себя и,
>>>>> наверное, заинтересованы в их работоспособности.
>>>> Да, просто когда договорённости с берега меняются
>>>> в процессе (пусть и межгалактического перелёта) --
>>>> лучше это обозначать, чем потом удивляться.
>>>>
>>> Дима напомнил об известной проблеме и предложил решение.
>>> Вы не знали о проблеме или у Вас есть  иное предложение о её решении?
>>> К сожалению, рассылки извещений не работают.
>>>
>>>
>>>> Например, блицкриг "все на gear" аккурат в годы подъёма
>>>> убунты обошёлся команде весьма дорого.
>>>>
>>> Вам есть что сказать о возможном решении проблемы ftbfs или Вы просто
>>> хотите увести обсуждение в сторону?
>> Мне — есть. Предлагаемый период месяц слишком мал, т.к. мейнтенер
>> может уйти на месяц в отпуск (не зависимо от того где он
>> работает), а в отпуске человек имеет право отдыхать, а не бросать
>> всё потому что иначе удалят его пакеты.
>
> Не говоря уже о том, что у людей бывает работа и ему надо всё бросить 
> и идти чинить свою гору пакетов.
>
>
> Принудительная форма решения этой проблемы породит просто новые 
> способы её обхода. Как я уже однажды заметил, не обязательно чинить 
> пакет, от которого зависит какой-то другой пакет, потому что его точно 
> не удалят. Не обязательно чинить общеупотребимые пакеты типа 
> браузеров, потому что их тоже не удалят.
>
> Мне больше нравится добровольная форма решения, предложенная когда-то 
> mike@. Устраивать что-то вроде субботников каждый месяц, когда люди 
> могут собраться и абстрагировавшись от всего заняться исправлением ftbfs.
>
> Кроме всего прочего, человек может просто элементарно не знать, как 
> починить пакет. На озвученном выше мероприятии, коллеги могут ему 
> чем-то помочь.

Субботники не работают без принуждения. Как устроитель пары BugDay я 
могу об этом сказать.

Практика кардинальной чистки пакетов разумна. Это позволит 
сосредоточиться именно на тех пакетах, которые нужны другим и удалить 
откровенно неподдерживаемые пакеты. А вернуть удалённые при желании 
очень просто.

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Andrey Savchenko]

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

On Mon, 5 Apr 2021 09:28:14 +0300 Andrey Cherepanov wrote:
> 05.04.2021 08:23, Grigory Ustinov пишет:
[...]
> > Мейнтейнеров много хороших и разных. Некоторые поддерживают десяток 
> > пакетов, некоторые сотню, а некоторые тысячу, а срок исправления для 
> > всех одинаковый. Есть у нас и такие мейнтейнеры, которые в текстовом 
> > файле есть, а по факту их нет.
> >
> > Лично моё мнение, что удаление ftbfs через месяц приведёт к огромному 
> > количеству проблем, начиная с мощного уменьшения пакетной базы и 
> > заканчивая уменьшением количества мейнтейнеров из коммьюнити.
> 
> Даже если все пакеты из FTBFS будут удалены, не порождая анметов, это не 
> превысит 1%.

Но ведь породят, и их зависимости породят. В итоге будет развесистый
граф и где-нибудь за год половина репозитория будет вынесена, вместе
с половиной мейнтенеров.

> Социальная сторона также некритична: если мейнтейнер не чинил пакет, то 
> и реакции на удаление вряд ли стоит ждать.

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

Вот пример реакции: они сломали мой пакет (новая «дурацкая» проверка
в сборочнице, новая версия используемой библиотеки с разломанным
API, новый глючный тулчейн, новая среда сборочницы с посыпавшимися
системными вызовами, проблема только на редкой архитектуре и т.д.
и т.п.), не дали времени на исправление (FTBFS в месяц) или не дали
возможности для отладки (не у всех мейнтенеров есть доступ ко всем
архитектурам, qemu не всегда вариант; специфические для beehive
ошибки тоже простым смертным не отладить) и просто выносят — ну
и в баню это всё куда подальше.

Честно, подобные эмоции порой возникают на фоне постоянного
закручивания гаек ради не совсем понятно чего.

> > Не говоря уже о том, что у людей бывает работа и ему надо всё бросить 
> > и идти чинить свою гору пакетов.
> >
> >
> > Принудительная форма решения этой проблемы породит просто новые 
> > способы её обхода. Как я уже однажды заметил, не обязательно чинить 
> > пакет, от которого зависит какой-то другой пакет, потому что его точно 
> > не удалят. Не обязательно чинить общеупотребимые пакеты типа 
> > браузеров, потому что их тоже не удалят.
> >
> > Мне больше нравится добровольная форма решения, предложенная когда-то 
> > mike@. Устраивать что-то вроде субботников каждый месяц, когда люди 
> > могут собраться и абстрагировавшись от всего заняться исправлением ftbfs.
> >
> > Кроме всего прочего, человек может просто элементарно не знать, как 
> > починить пакет. На озвученном выше мероприятии, коллеги могут ему 
> > чем-то помочь.
> 
> Субботники не работают без принуждения. Как устроитель пары BugDay я 
> могу об этом сказать.
> 
> Практика кардинальной чистки пакетов разумна. Это позволит 
> сосредоточиться именно на тех пакетах, которые нужны другим и удалить 
> откровенно неподдерживаемые пакеты.

Здесь важен баланс и нужно разбираться из-за чего (и кого) возникла
проблема.

У нас есть некоторый перекос: для мейнтенеров одних библиотек
(и в целом пакетов) есть требование чинить всё, что сломало их
обновление; для мейнтенеров других всё наоборот и они требуют
чинить всех остальных всё то, что сломали их обновления. По-моему,
здесь не хватает справедливого policy.

> А вернуть удалённые при желании очень просто.

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

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Andrey Cherepanov]

05.04.2021 17:31, Andrey Savchenko пишет:
> On Mon, 5 Apr 2021 09:28:14 +0300 Andrey Cherepanov wrote:
>> 05.04.2021 08:23, Grigory Ustinov пишет:
> [...]
>>> Мейнтейнеров много хороших и разных. Некоторые поддерживают десяток
>>> пакетов, некоторые сотню, а некоторые тысячу, а срок исправления для
>>> всех одинаковый. Есть у нас и такие мейнтейнеры, которые в текстовом
>>> файле есть, а по факту их нет.
>>>
>>> Лично моё мнение, что удаление ftbfs через месяц приведёт к огромному
>>> количеству проблем, начиная с мощного уменьшения пакетной базы и
>>> заканчивая уменьшением количества мейнтейнеров из коммьюнити.
>> Даже если все пакеты из FTBFS будут удалены, не порождая анметов, это не
>> превысит 1%.
> Но ведь породят, и их зависимости породят. В итоге будет развесистый
> граф и где-нибудь за год половина репозитория будет вынесена, вместе
> с половиной мейнтенеров.
Если задание на удаление из-за анметов не будет выполнено, это повод 
исправить пакет. Не надо драматизировать ситуацию и призывать к 
тотальному удалению всех непересобираемых пакетов. Задача, как я 
понимаю, избавиться от откровенно ненужных и непересобираемых пакетов. 
Когда у нас три сотни непересобираемых пакетов, то нет мотивации 
сосредоточиться на починке. Когда три десятка и эти пакеты нужны - 
ситуация более приемлемая.
>
>> Социальная сторона также некритична: если мейнтейнер не чинил пакет, то
>> и реакции на удаление вряд ли стоит ждать.
> Не согласен. С социальной точки зрения критически важно то, как
> мейнтенеры ощущают отношение к себе, особенно когда речь
> о добровольцах, а не о сотрудниках на зарплате.
>
> Вот пример реакции: они сломали мой пакет (новая «дурацкая» проверка
> в сборочнице, новая версия используемой библиотеки с разломанным
> API, новый глючный тулчейн, новая среда сборочницы с посыпавшимися
> системными вызовами, проблема только на редкой архитектуре и т.д.
> и т.п.), не дали времени на исправление (FTBFS в месяц) или не дали
> возможности для отладки (не у всех мейнтенеров есть доступ ко всем
> архитектурам, qemu не всегда вариант; специфические для beehive
> ошибки тоже простым смертным не отладить) и просто выносят — ну
> и в баню это всё куда подальше.
>
> Честно, подобные эмоции порой возникают на фоне постоянного
> закручивания гаек ради не совсем понятно чего.
Есть статистика?
>
>>> Не говоря уже о том, что у людей бывает работа и ему надо всё бросить
>>> и идти чинить свою гору пакетов.
>>>
>>>
>>> Принудительная форма решения этой проблемы породит просто новые
>>> способы её обхода. Как я уже однажды заметил, не обязательно чинить
>>> пакет, от которого зависит какой-то другой пакет, потому что его точно
>>> не удалят. Не обязательно чинить общеупотребимые пакеты типа
>>> браузеров, потому что их тоже не удалят.
>>>
>>> Мне больше нравится добровольная форма решения, предложенная когда-то
>>> mike@. Устраивать что-то вроде субботников каждый месяц, когда люди
>>> могут собраться и абстрагировавшись от всего заняться исправлением ftbfs.
>>>
>>> Кроме всего прочего, человек может просто элементарно не знать, как
>>> починить пакет. На озвученном выше мероприятии, коллеги могут ему
>>> чем-то помочь.
>> Субботники не работают без принуждения. Как устроитель пары BugDay я
>> могу об этом сказать.
>>
>> Практика кардинальной чистки пакетов разумна. Это позволит
>> сосредоточиться именно на тех пакетах, которые нужны другим и удалить
>> откровенно неподдерживаемые пакеты.
> Здесь важен баланс и нужно разбираться из-за чего (и кого) возникла
> проблема.
>
> У нас есть некоторый перекос: для мейнтенеров одних библиотек
> (и в целом пакетов) есть требование чинить всё, что сломало их
> обновление; для мейнтенеров других всё наоборот и они требуют
> чинить всех остальных всё то, что сломали их обновления. По-моему,
> здесь не хватает справедливого policy.
Кто напишет?
>
>> А вернуть удалённые при желании очень просто.
> На самом деле не всегда, например, когда вынесли следом половину
> нужных зависимостей или разломали фичи оставшихся.

Примеры?

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Grigory Ustinov]

05.04.2021 17:42, Andrey Cherepanov пишет:
> 05.04.2021 17:31, Andrey Savchenko пишет:
>> On Mon, 5 Apr 2021 09:28:14 +0300 Andrey Cherepanov wrote:
>>> 05.04.2021 08:23, Grigory Ustinov пишет:
>> [...]
>>>> Мейнтейнеров много хороших и разных. Некоторые поддерживают десяток
>>>> пакетов, некоторые сотню, а некоторые тысячу, а срок исправления для
>>>> всех одинаковый. Есть у нас и такие мейнтейнеры, которые в текстовом
>>>> файле есть, а по факту их нет.
>>>>
>>>> Лично моё мнение, что удаление ftbfs через месяц приведёт к огромному
>>>> количеству проблем, начиная с мощного уменьшения пакетной базы и
>>>> заканчивая уменьшением количества мейнтейнеров из коммьюнити.
>>> Даже если все пакеты из FTBFS будут удалены, не порождая анметов, 
>>> это не
>>> превысит 1%.
>> Но ведь породят, и их зависимости породят. В итоге будет развесистый
>> граф и где-нибудь за год половина репозитория будет вынесена, вместе
>> с половиной мейнтенеров.
> Если задание на удаление из-за анметов не будет выполнено, это повод 
> исправить пакет. Не надо драматизировать ситуацию и призывать к 
> тотальному удалению всех непересобираемых пакетов. Задача, как я 
> понимаю, избавиться от откровенно ненужных и непересобираемых пакетов. 
> Когда у нас три сотни непересобираемых пакетов, то нет мотивации 
> сосредоточиться на починке. Когда три десятка и эти пакеты нужны - 
> ситуация более приемлемая.
Есть мотивация. Я Вот последнюю неделю этим очень даже плотно занимаюсь. 
Я не разделяю мнения о том, что если кому-нибудь надо, то он соберёт 
пакет. Если мне нужен пакет для _чего-то_, я делаю apt-cache search 
что-то и выбираю из этого, а не лезу в поисковик и не ищу, какой же мне 
нужен пакет. Кроме того, понятие "откровенно ненужный" у каждого разное. 
У нас есть люди, которым откровенно не нужны все gui приложения. И я 
сейчас говорю вовсе не про тех, кто работает с серверами=)
>>
>>> Социальная сторона также некритична: если мейнтейнер не чинил пакет, то
>>> и реакции на удаление вряд ли стоит ждать.
>> Не согласен. С социальной точки зрения критически важно то, как
>> мейнтенеры ощущают отношение к себе, особенно когда речь
>> о добровольцах, а не о сотрудниках на зарплате.
>>
>> Вот пример реакции: они сломали мой пакет (новая «дурацкая» проверка
>> в сборочнице, новая версия используемой библиотеки с разломанным
>> API, новый глючный тулчейн, новая среда сборочницы с посыпавшимися
>> системными вызовами, проблема только на редкой архитектуре и т.д.
>> и т.п.), не дали времени на исправление (FTBFS в месяц) или не дали
>> возможности для отладки (не у всех мейнтенеров есть доступ ко всем
>> архитектурам, qemu не всегда вариант; специфические для beehive
>> ошибки тоже простым смертным не отладить) и просто выносят — ну
>> и в баню это всё куда подальше.
>>
>> Честно, подобные эмоции порой возникают на фоне постоянного
>> закручивания гаек ради не совсем понятно чего.
> Есть статистика?
>>
>>>> Не говоря уже о том, что у людей бывает работа и ему надо всё бросить
>>>> и идти чинить свою гору пакетов.
>>>>
>>>>
>>>> Принудительная форма решения этой проблемы породит просто новые
>>>> способы её обхода. Как я уже однажды заметил, не обязательно чинить
>>>> пакет, от которого зависит какой-то другой пакет, потому что его точно
>>>> не удалят. Не обязательно чинить общеупотребимые пакеты типа
>>>> браузеров, потому что их тоже не удалят.
>>>>
>>>> Мне больше нравится добровольная форма решения, предложенная когда-то
>>>> mike@. Устраивать что-то вроде субботников каждый месяц, когда люди
>>>> могут собраться и абстрагировавшись от всего заняться исправлением 
>>>> ftbfs.
>>>>
>>>> Кроме всего прочего, человек может просто элементарно не знать, как
>>>> починить пакет. На озвученном выше мероприятии, коллеги могут ему
>>>> чем-то помочь.
>>> Субботники не работают без принуждения. Как устроитель пары BugDay я
>>> могу об этом сказать.
>>>
>>> Практика кардинальной чистки пакетов разумна. Это позволит
>>> сосредоточиться именно на тех пакетах, которые нужны другим и удалить
>>> откровенно неподдерживаемые пакеты.
>> Здесь важен баланс и нужно разбираться из-за чего (и кого) возникла
>> проблема.
>>
>> У нас есть некоторый перекос: для мейнтенеров одних библиотек
>> (и в целом пакетов) есть требование чинить всё, что сломало их
>> обновление; для мейнтенеров других всё наоборот и они требуют
>> чинить всех остальных всё то, что сломали их обновления. По-моему,
>> здесь не хватает справедливого policy.

Например при обновлении python3 нужно, чтобы все пакеты с ним 
собирались. Большая часть времени и усилий уходит именно на это. И 
учитывая, что большинство пакетов стоят на python@, их приходится чинить 
одному человеку. Я ощущаю острую социальную несправедливость и готов 
участвовать в компании тех, кто будет писать policy, заставляющее чинить 
пакеты для других обновлений.

У нас же есть ufb список, можно при обновлении пакета сразу пересобирать 
с ним то, что от него зависит. Если твоё обновление ломает сборку других 
пакетов, будь добр исправь его или попроси ответственных за эти пакеты 
исправить. Всё как с python3.

> Кто напишет?
>>
>>> А вернуть удалённые при желании очень просто.
>> На самом деле не всегда, например, когда вынесли следом половину
>> нужных зависимостей или разломали фичи оставшихся.
>
> Примеры?

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Anton Farygin]

On 05.04.2021 18:07, Grigory Ustinov wrote:
> У нас же есть ufb список, можно при обновлении пакета сразу 
> пересобирать с ним то, что от него зависит. Если твоё обновление 
> ломает сборку других пакетов, будь добр исправь его или попроси 
> ответственных за эти пакеты исправить. Всё как с python3. 

Это не так просто - мы тут в паралельной реальности обсуждали - что бы 
выяснить на какие пакеты окажет влияние сборочное задание - нужно 
попробовать собрать все пакеты репозитория со сборочным заданием.

Других вариантов, к сожалению, нет - информация о том, кто и с чем 
собирался очень быстро устаревает, а в новом задании могут быть такие 
новые пакеты, которые сломают сборку старых пакетов.

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Andrey Savchenko]

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

On Mon, 5 Apr 2021 17:42:41 +0300 Andrey Cherepanov wrote:
> 05.04.2021 17:31, Andrey Savchenko пишет:
> > On Mon, 5 Apr 2021 09:28:14 +0300 Andrey Cherepanov wrote:
> >> 05.04.2021 08:23, Grigory Ustinov пишет:
> > [...]
> >>> Мейнтейнеров много хороших и разных. Некоторые поддерживают десяток
> >>> пакетов, некоторые сотню, а некоторые тысячу, а срок исправления для
> >>> всех одинаковый. Есть у нас и такие мейнтейнеры, которые в текстовом
> >>> файле есть, а по факту их нет.
> >>>
> >>> Лично моё мнение, что удаление ftbfs через месяц приведёт к огромному
> >>> количеству проблем, начиная с мощного уменьшения пакетной базы и
> >>> заканчивая уменьшением количества мейнтейнеров из коммьюнити.
> >> Даже если все пакеты из FTBFS будут удалены, не порождая анметов, это не
> >> превысит 1%.
> > Но ведь породят, и их зависимости породят. В итоге будет развесистый
> > граф и где-нибудь за год половина репозитория будет вынесена, вместе
> > с половиной мейнтенеров.
> Если задание на удаление из-за анметов не будет выполнено, это повод 
> исправить пакет. Не надо драматизировать ситуацию и призывать к 
> тотальному удалению всех непересобираемых пакетов. Задача, как я 
> понимаю, избавиться от откровенно ненужных и непересобираемых пакетов. 

Проблема в том, что нет единого критерия нужности. В своё время
решили, что HPC нам не нужен: в итоге грохнули torque, slurm, hpl,
зарезали на уровне сборочницы саму возможность использования
альтернативных реализаций blas и lapack; openmpi откровенно на
ладан дышит. В общем, убита вся экосистема ради теоретических благ.

> >> Социальная сторона также некритична: если мейнтейнер не чинил пакет, то
> >> и реакции на удаление вряд ли стоит ждать.
> > Не согласен. С социальной точки зрения критически важно то, как
> > мейнтенеры ощущают отношение к себе, особенно когда речь
> > о добровольцах, а не о сотрудниках на зарплате.
> >
> > Вот пример реакции: они сломали мой пакет (новая «дурацкая» проверка
> > в сборочнице, новая версия используемой библиотеки с разломанным
> > API, новый глючный тулчейн, новая среда сборочницы с посыпавшимися
> > системными вызовами, проблема только на редкой архитектуре и т.д.
> > и т.п.), не дали времени на исправление (FTBFS в месяц) или не дали
> > возможности для отладки (не у всех мейнтенеров есть доступ ко всем
> > архитектурам, qemu не всегда вариант; специфические для beehive
> > ошибки тоже простым смертным не отладить) и просто выносят — ну
> > и в баню это всё куда подальше.
> >
> > Честно, подобные эмоции порой возникают на фоне постоянного
> > закручивания гаек ради не совсем понятно чего.
> Есть статистика?

Статистика чего? Личных эмоций? Или того, как люди уходили из тима
за всю его историю? Первую я не собираю. Вторую можно пособирать
у старожилов, но точно определить причины ухода человека в общем
случае сложно.

> > У нас есть некоторый перекос: для мейнтенеров одних библиотек
> > (и в целом пакетов) есть требование чинить всё, что сломало их
> > обновление; для мейнтенеров других всё наоборот и они требуют
> > чинить всех остальных всё то, что сломали их обновления. По-моему,
> > здесь не хватает справедливого policy.
> Кто напишет?

Прежде чем писать, нужно обсудить что сообщество считает разумным.

Будет ли разумным требовать даунстримы (т.е. мейнтенеров зависимых
пакетов) исправлять все проблемы, вызванные обновлением
зависимости, если речь идёт не про ошибку в арстримном пакете,
а про изменение API и т.п.?

Мне представляется, что для тяжёлых пакетов — т.е. для того, что
тянет за собой большой граф зависимостей — целесообразно проводить
тестирование перед реальным обновлением. И здесь мы упираемся
в очередную проблему нашей чудо-сборочницы: в общем случае нельзя
взять и построить полный граф сборочных зависимостей.

> >> А вернуть удалённые при желании очень просто.
> > На самом деле не всегда, например, когда вынесли следом половину
> > нужных зависимостей или разломали фичи оставшихся.
> 
> Примеры?

Любая сложная экосистема. Выше описан пример HPC: системы
управления заданиями у нас вырезаны на корню, возможности
переключения альтернатив стандартных вычислительных библиотек
сведены к почти нулю — а в мире HPC это очень востребовано!

В итоге нет возможности полноценно собрать и обновить openmpi.
Не говоря о том, что альтеранативные реализации MPI — ну тот же
mpich2 тоже вырезаны и добавить их будет очень тяжело. Ага, снова
пресловутые duplicate provides.

Как результат, возможность сборки вычислительного научного софта
в Альте существенно ограничена целым клубком проблем и «легко взять
и вернуть» отдельный пакет уже невозможно, т.к. утеряна экосистема.
Ну lammps, например.

Аналогичные проблемы могут быть и с другими экосистемами. Например,
у нас раздавались предложения удалить ruby из репозитория и были
массово удалены зависимости из ряда пакетов — _если_ это будет
полностью осуществлено, последствия будут катастрофическими
и просто взять и вернуть, скажем тот же mkvtoolnix будет уже
невозможно.

Есть и зависшая в воздухе проблема с TeXLive: экосистема сложная,
сборочница оказалась технически неспособна обработать её сборку.
Но ответственные лица решили, что так и должно быть.  В итоге
собрано костыльным способом, чтоб было хоть что-то, что,
безусловно, тоже ограничивает возможность использования и развития
экосистемы.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Paul Wolneykien]

В Tue, 6 Apr 2021 13:04:24 +0300
Andrey Savchenko <bircoph@altlinux.org> пишет:

> Проблема в том, что нет единого критерия нужности. В своё время
> решили, что HPC нам не нужен: в итоге грохнули torque, slurm, hpl,
> зарезали на уровне сборочницы саму возможность использования
> альтернативных реализаций blas и lapack; openmpi откровенно на
> ладан дышит. В общем, убита вся экосистема ради теоретических благ.

  Я периодически задумываюсь о том, как починить сборку BLAS. Говорил с
slazav@ о том, чтобы собирать BLAS из исходников внутри LAPACK. Если
тебе интересно, можем вместе на эту тему подумать.

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Dmitry V. Levin]

On Tue, Apr 06, 2021 at 01:04:24PM +0300, Andrey Savchenko wrote:
[...]
> Проблема в том, что нет единого критерия нужности. В своё время
> решили, что HPC нам не нужен: в итоге грохнули torque, slurm, hpl,
> зарезали на уровне сборочницы саму возможность использования
> альтернативных реализаций blas и lapack; openmpi откровенно на
> ладан дышит. В общем, убита вся экосистема ради теоретических благ.

"В своё время решили" - это ерунда какая-то.
Пакеты устарели, сломались, и удалились, потому что не нашлось никого,
кто бы о них позаботился.
Это иллюзия, будто сложные пакеты можно собрать один раз, а дальше они
сами себя будут мантейнить.  Очевидно, за ними нужен постоянный уход.

"My dear, here we must run as fast as we can, just to stay in place.
And if you wish to go anywhere you must run twice as fast as that."


-- 
ldv

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Anton Farygin]

On 06.04.2021 13:04, Andrey Savchenko wrote:
> Мне представляется, что для тяжёлых пакетов — т.е. для того, что
> тянет за собой большой граф зависимостей — целесообразно проводить
> тестирование перед реальным обновлением. И здесь мы упираемся
> в очередную проблему нашей чудо-сборочницы: в общем случае нельзя
> взять и построить полный граф сборочных зависимостей.

Ух, тема очень интересная и у меня уже что-то для этого есть.

По крайней мере вот результат: task #268975 ~160 пакетов с очень 
тяжёлыми зависимостями друг на друга по сборке и runtime собираются за 
два присеста.

Но в процессе разборок с этой темой выяснилось, что нужно много чего 
переделывать, но и в этом тоже пока не видно ничего нерешаемого.


а то, что на данный момент есть можно получить вот так:

curl -s 
"https://repodb.basealt.space/what_depends_src?name=ocaml&branch=sisyphus&deep=2&reqfilter=ocaml"|jq 
-r .

Работает, правда, только с состоянием опубликованного репозитория и не 
учитывает локальные пакеты. Ну и для данных берёт BR из SRC.RPM со всеми 
вытекающими проблемами.


deep реально считается до 4 для не очень больших графов, всё что выше 
уходит за таймлимит в 30 секунд, но уже понятно как оптимизировать.

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Anton Farygin]

On 06.04.2021 14:53, Anton Farygin wrote:
> curl -s 
> "https://repodb.basealt.space/what_depends_src?name=ocaml&branch=sisyphus&deep=2&reqfilter=ocaml"|jq 
> -r .
>
> Работает, правда, только с состоянием опубликованного репозитория и не 
> учитывает локальные пакеты. Ну и для данных берёт BR из SRC.RPM со 
> всеми вытекающими проблемами.

Да, забыл добавить - выход этого запроса отсортирован в порядке сборки 
по зависимостям, но в сортировке могут быть баги - конкретно здесь пяток 
пакетов пришлось переставить.

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Vladimir D. Seleznev]

On Tue, Apr 06, 2021 at 01:04:24PM +0300, Andrey Savchenko wrote:
> On Mon, 5 Apr 2021 17:42:41 +0300 Andrey Cherepanov wrote:
> > 05.04.2021 17:31, Andrey Savchenko пишет:
> > > On Mon, 5 Apr 2021 09:28:14 +0300 Andrey Cherepanov wrote:
> > >> 05.04.2021 08:23, Grigory Ustinov пишет:
> [skip]
> 
> Любая сложная экосистема. Выше описан пример HPC: системы
> управления заданиями у нас вырезаны на корню, возможности
> переключения альтернатив стандартных вычислительных библиотек
> сведены к почти нулю — а в мире HPC это очень востребовано!
> 
> В итоге нет возможности полноценно собрать и обновить openmpi.
> Не говоря о том, что альтеранативные реализации MPI — ну тот же
> mpich2 тоже вырезаны и добавить их будет очень тяжело. Ага, снова
> пресловутые duplicate provides.
> 
> Как результат, возможность сборки вычислительного научного софта
> в Альте существенно ограничена целым клубком проблем и «легко взять
> и вернуть» отдельный пакет уже невозможно, т.к. утеряна экосистема.
> Ну lammps, например.

Сходно проблеме курицы и яйца. Пользуются ли на Альте HPC и научным
софтом? Если пользуются, почему не ухаживают? А если не пользуются —
зачем распыляться?  Конечно, хочется, чтобы был как можно более широкий
охват аудитории, и чтобы было как можно больше поддержки технологий. Но
само ничего не будет: если не сопровождать такое программное
обеспечение, оно само себя не сопроводит. А устаревшее и поломанное не
делает лучше репозиторию.

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

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Arseny Maslennikov]

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

On Tue, Apr 06, 2021 at 04:36:52PM +0300, Vladimir D. Seleznev wrote:
> On Tue, Apr 06, 2021 at 01:04:24PM +0300, Andrey Savchenko wrote:
> > On Mon, 5 Apr 2021 17:42:41 +0300 Andrey Cherepanov wrote:
> > > 05.04.2021 17:31, Andrey Savchenko пишет:
> > > > On Mon, 5 Apr 2021 09:28:14 +0300 Andrey Cherepanov wrote:
> > > >> 05.04.2021 08:23, Grigory Ustinov пишет:
> > [skip]
> > 
> > Любая сложная экосистема. Выше описан пример HPC: системы
> > управления заданиями у нас вырезаны на корню, возможности
> > переключения альтернатив стандартных вычислительных библиотек
> > сведены к почти нулю — а в мире HPC это очень востребовано!
> > 
> > В итоге нет возможности полноценно собрать и обновить openmpi.
> > Не говоря о том, что альтеранативные реализации MPI — ну тот же
> > mpich2 тоже вырезаны и добавить их будет очень тяжело. Ага, снова
> > пресловутые duplicate provides.
> > 
> > Как результат, возможность сборки вычислительного научного софта
> > в Альте существенно ограничена целым клубком проблем и «легко взять
> > и вернуть» отдельный пакет уже невозможно, т.к. утеряна экосистема.
> > Ну lammps, например.
> 
> Сходно проблеме курицы и яйца. Пользуются ли на Альте HPC и научным
> софтом? Если пользуются, почему не ухаживают? А если не пользуются —
> зачем распыляться?

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

> Конечно, хочется, чтобы был как можно более широкий
> охват аудитории, и чтобы было как можно больше поддержки технологий. Но
> само ничего не будет:

Верно.
Если никто не захочет убедить кого-то, кому надо, сделать суперкомпьютер
или вычкомплекс на альте — сами они не появятся.

А простые-рядовые пользователи не будут отлаживать своё ПО на локальных
машинах с альтом, если предполагаемая площадка у них на какой-нибудь
кентоси (или роккилинуксе, не так важно); они лучше "проверенную" и
"умудрённую опытом" кентось себе на машину поставят, а там окажется, что
ей и как десктопом можно пользоваться (спасибо гномерам). Мне довелось
лично таких пользователей Ломоносова в МГУ наблюдать, они были довольны
результатом.

> если не сопровождать такое программное
> обеспечение, оно само себя не сопроводит. А устаревшее и поломанное не
> делает лучше репозиторию.
> 
> В любом случае, не стоит драматизировать, всё всегда можно вернуть, а
> вместо костылей придумать прямые решения. Но просто собрать что-то
> недостаточно, нужно сопровождать.

А если см. выше, то и будет зачем сопровождать.

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

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Vladimir D. Seleznev]

On Mon, Apr 05, 2021 at 12:36:18AM +0300, Michael Shigorin wrote:
> Да, просто когда договорённости с берега меняются
> в процессе (пусть и межгалактического перелёта) --
> лучше это обозначать, чем потом удивляться.
> 
> Например, блицкриг "все на gear" аккурат в годы подъёма
> убунты обошёлся команде весьма дорого.

Великий исход из команды во время перехода на gear в годы подъёма
Убунты. Убунты, где форматов и вариантов сопровождения исходных пакетов
невообразимое количество.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Arseny Maslennikov]

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

On Tue, Apr 06, 2021 at 04:47:33PM +0300, Vladimir D. Seleznev wrote:
> On Mon, Apr 05, 2021 at 12:36:18AM +0300, Michael Shigorin wrote:
> > Да, просто когда договорённости с берега меняются
> > в процессе (пусть и межгалактического перелёта) --
> > лучше это обозначать, чем потом удивляться.
> > 
> > Например, блицкриг "все на gear" аккурат в годы подъёма
> > убунты обошёлся команде весьма дорого.
> 
> Великий исход из команды во время перехода на gear в годы подъёма
> Убунты. Убунты, где форматов и вариантов сопровождения исходных пакетов
> невообразимое количество.

Вынужден повторить слова Миши: Не в саму убунту, а в годы её подъёма.
А исход — скорее в дебиан, или вовсе из сопровождения пакетов
репозиториев свободных ОС.

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

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Anton Farygin]

On 04.04.2021 23:16, Dmitry V. Levin wrote:
> On Sun, Apr 04, 2021 at 10:15:00PM +0300, Anton Farygin wrote:
>> On 04.04.2021 21:49, Dmitry V. Levin wrote:
>>> On Tue, Mar 30, 2021 at 05:23:47PM +0300, Dmitry V. Levin wrote:
>>> [...]
>>>> Для того, чтобы укладываться с исправлением всех ftbfs в 3 месяца,
>>>> я предлагаю следующее изменение в сопровождении пакетов:
>>>> - мантейнерам начинать исправлять ftbfs сразу, как только ftbfs возникают;
>>>> - сформировать группу мантейнеров, которая будет исправлять ftbfs в
>>>>     пакетах других мантейнеров:
>>>>     + для пакетов на @nobody - сразу, как только ftbfs возникают;
>>>>     + для остальных пакетов - 4 недели спустя после возникновения ftbfs.
>>> Поскольку возражений не поступило, будем считать, что все согласны
>>> с этим предложением. :)
>>>
>> А чем это будет отличаться от текущей ситуации ,
> - мантейнеры не будут откладывать исправление на полгода, потому что
>    уже через месяц их пакеты начнут удаляться;
Удаляться или исправляться ? Удалять можно уже сейчас начинать.
> - мы сформируем группу добровольцев, которые начнут исправлять ftbfs
>    в пакетах других мантейнеров.
>
> Насколько я помню, группа @qa когда-то была создана для этих целей,
> но со временем переродилась.
Да.
>
> Можно создать группу с другим именем, если понадобится.

Идея в целом мне нравится, но на _удаление_ пакетов надо ввести запрет.

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

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Vladimir D. Seleznev]

On Mon, Apr 05, 2021 at 08:06:04AM +0300, Anton Farygin wrote:
> On 04.04.2021 23:16, Dmitry V. Levin wrote:
> > On Sun, Apr 04, 2021 at 10:15:00PM +0300, Anton Farygin wrote:
> >> On 04.04.2021 21:49, Dmitry V. Levin wrote:
> >>> On Tue, Mar 30, 2021 at 05:23:47PM +0300, Dmitry V. Levin wrote:
> >>> [...]
> >>>> Для того, чтобы укладываться с исправлением всех ftbfs в 3 месяца,
> >>>> я предлагаю следующее изменение в сопровождении пакетов:
> >>>> - мантейнерам начинать исправлять ftbfs сразу, как только ftbfs возникают;
> >>>> - сформировать группу мантейнеров, которая будет исправлять ftbfs в
> >>>>     пакетах других мантейнеров:
> >>>>     + для пакетов на @nobody - сразу, как только ftbfs возникают;
> >>>>     + для остальных пакетов - 4 недели спустя после возникновения ftbfs.
> >>> Поскольку возражений не поступило, будем считать, что все согласны
> >>> с этим предложением. :)
> >>>
> >> А чем это будет отличаться от текущей ситуации ,
> > - мантейнеры не будут откладывать исправление на полгода, потому что
> >    уже через месяц их пакеты начнут удаляться;
> Удаляться или исправляться ? Удалять можно уже сейчас начинать.
> > - мы сформируем группу добровольцев, которые начнут исправлять ftbfs
> >    в пакетах других мантейнеров.
> >
> > Насколько я помню, группа @qa когда-то была создана для этих целей,
> > но со временем переродилась.
> Да.
> >
> > Можно создать группу с другим именем, если понадобится.
> 
> Идея в целом мне нравится, но на _удаление_ пакетов надо ввести запрет.

Почему?

> То, что должна быть группа людей, которая исправляет пакеты - у меня 
> сомнений нет.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Anton Farygin]

On 05.04.2021 12:38, Vladimir D. Seleznev wrote:
>>> Можно создать группу с другим именем, если понадобится.
>> Идея в целом мне нравится, но на_удаление_  пакетов надо ввести запрет.
> Почему?
>
Это слишком простой и очевидный способ исправления FTBFS, к тому же 
сейчас есть работающий механизм удаления таких пакетов, в этом я не вижу 
смысла что-то менять.

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Dmitry V. Levin]

On Mon, Apr 05, 2021 at 01:33:06PM +0300, Anton Farygin wrote:
> On 05.04.2021 12:38, Vladimir D. Seleznev wrote:
> >>> Можно создать группу с другим именем, если понадобится.
> >> Идея в целом мне нравится, но на_удаление_  пакетов надо ввести запрет.
> > Почему?
> >
> Это слишком простой и очевидный способ исправления FTBFS, к тому же 
> сейчас есть работающий механизм удаления таких пакетов, в этом я не вижу 
> смысла что-то менять.

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


-- 
ldv

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Anton Farygin]

On 05.04.2021 13:45, Dmitry V. Levin wrote:
> On Mon, Apr 05, 2021 at 01:33:06PM +0300, Anton Farygin wrote:
>> On 05.04.2021 12:38, Vladimir D. Seleznev wrote:
>>>>> Можно создать группу с другим именем, если понадобится.
>>>> Идея в целом мне нравится, но на_удаление_  пакетов надо ввести запрет.
>>> Почему?
>>>
>> Это слишком простой и очевидный способ исправления FTBFS, к тому же
>> сейчас есть работающий механизм удаления таких пакетов, в этом я не вижу
>> смысла что-то менять.
> Этот работающий механизм простой, поэтому когда при удалении возникают
> анметы, нужен человек, чтобы принять решение, что делать дальше.
>
>
Ну да, и с анметами тоже разбираться через три месяца.

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Dmitry V. Levin]

On Mon, Apr 05, 2021 at 01:49:47PM +0300, Anton Farygin wrote:
> On 05.04.2021 13:45, Dmitry V. Levin wrote:
> > On Mon, Apr 05, 2021 at 01:33:06PM +0300, Anton Farygin wrote:
> >> On 05.04.2021 12:38, Vladimir D. Seleznev wrote:
> >>>>> Можно создать группу с другим именем, если понадобится.
> >>>> Идея в целом мне нравится, но на_удаление_  пакетов надо ввести запрет.
> >>> Почему?
> >>>
> >> Это слишком простой и очевидный способ исправления FTBFS, к тому же
> >> сейчас есть работающий механизм удаления таких пакетов, в этом я не вижу
> >> смысла что-то менять.
> > Этот работающий механизм простой, поэтому когда при удалении возникают
> > анметы, нужен человек, чтобы принять решение, что делать дальше.
> >
> Ну да, и с анметами тоже разбираться через три месяца.

Через три месяца уже надо закончить разбираться.


-- 
ldv

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Anton Farygin]

On 05.04.2021 13:58, Dmitry V. Levin wrote:
> On Mon, Apr 05, 2021 at 01:49:47PM +0300, Anton Farygin wrote:
>> On 05.04.2021 13:45, Dmitry V. Levin wrote:
>>> On Mon, Apr 05, 2021 at 01:33:06PM +0300, Anton Farygin wrote:
>>>> On 05.04.2021 12:38, Vladimir D. Seleznev wrote:
>>>>>>> Можно создать группу с другим именем, если понадобится.
>>>>>> Идея в целом мне нравится, но на_удаление_  пакетов надо ввести запрет.
>>>>> Почему?
>>>>>
>>>> Это слишком простой и очевидный способ исправления FTBFS, к тому же
>>>> сейчас есть работающий механизм удаления таких пакетов, в этом я не вижу
>>>> смысла что-то менять.
>>> Этот работающий механизм простой, поэтому когда при удалении возникают
>>> анметы, нужен человек, чтобы принять решение, что делать дальше.
>>>
>> Ну да, и с анметами тоже разбираться через три месяца.
> Через три месяца уже надо закончить разбираться.
Ок, срок можно и уменьшить, но он точно должен быть заметно больше 1 месяца.

Re: [devel] I: регулярные сборки =?utf-8?b?INGC0YPQu9GH0LXQudC90LA=?=, изменение в сопровождении пакетов

[Sergey Afonin]

On Monday 05 April 2021, Anton Farygin wrote:

> Ок, срок можно и уменьшить, но он точно должен быть заметно
> больше 1 месяца. 
 
Однозначно. Сразу полный отпуск редкость конечно, но возможен.
Да и если человек на две недели уехал, всё равно две недели 
после возвращения может своё накопившееся разгребать.

-- 
С уважением, Сергей Афонин.

Re: [devel] I: регулярные сборки =?utf-8?b?INGC0YPQu9GH0LXQudC90LA=?=, изменение в сопровождении пакетов

[Sergey Y. Afonin]

On Monday 05 April 2021, Anton Farygin wrote:

> > Можно создать группу с другим именем, если понадобится.
> 
> Идея в целом мне нравится, но на _удаление_ пакетов надо ввести запрет.
 
С исключением в виде ситуации, когда пакет мешает обновлению с CVE, например,
у библиотеки. Ну или какому-то ещё обновлению, которое будет признано важнее
пакета по каким-то критериям.

-- 
С уважением, Сергей Афонин

Re: [devel] I: регулярные сборки тулчейна, изменение в сопровождении пакетов

[Anton Farygin]

On 11.04.2021 15:14, Sergey Y. Afonin wrote:
> On Monday 05 April 2021, Anton Farygin wrote:
>
>>> Можно создать группу с другим именем, если понадобится.
>> Идея в целом мне нравится, но на _удаление_ пакетов надо ввести запрет.
>   
> С исключением в виде ситуации, когда пакет мешает обновлению с CVE, например,
> у библиотеки. Ну или какому-то ещё обновлению, которое будет признано важнее
> пакета по каким-то критериям.
>
Да в последних FTBFS даже в особо тяжёлых случаях обычно есть простые 
рецепты исправления.

Если же пакет мешает важному обновлению и не пересобирается, то мы, 
обычно, такие пакеты удаляем прямо в процессе важного обновления.