[devel] full list of unmets

[devel] full list of unmets

[Alexey Tourbin]

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

Робот, который отслеживает unmet'ы, был запущен ровно год назад.

Date: Tue, 21 Jun 2005 02:12:48 +0400
Subject: [devel] I: Sisyphus-20050621 unmets: -1 (122/70)

С тех пор количество unmet'ов значительно возросло:

Date: Thu, 15 Jun 2006 10:08:27 +0400
Subject: [Sisyphus-cybertalk] I: Sisyphus-20060615 i586 unmets: +14 -1 (265/155)

Минимальным значение unmet'ов было в марте.

Date: Sun, 26 Mar 2006 05:08:19 +0400
Subject: [Sisyphus-cybertalk] I: Sisyphus-20060326 i586 unmets: -3 (82/67)

Вот полный список unmet'ов.

AutoScan#0.99-alt0.1	libsnmp.so.9
LDAPExplorerTool#0.6-alt0.1	liblber-2.2.so.7
LDAPExplorerTool#0.6-alt0.1	libldap-2.2.so.7
amavisd-new-ldap-client#1:2.4.1-alt1	perl-ldap >= 0.32
apache2#2.0.55-alt8	libldap-2.2.so.7
apache2-mod_webauthldap#3.3.0-alt1	liblber-2.2.so.7
apache2-mod_webauthldap#3.3.0-alt1	libldap
apache2-mod_webauthldap#3.3.0-alt1	libldap-2.2.so.7
apt-indicator#0.0.4-alt7	libapt-pkg-libc6.3-6.so.0
asterisk-app_conference#20060510:1.3.7-alt1	asterisk = 1.3.7-alt1
asterisk-chan_sccp#20060408:1.3.1-alt1	asterisk = 1.3.1-alt1
asterisk-chan_ss7#20051114:0.8.3-alt5	asterisk = 1.3.7-alt1
asterisk-fax#20060603:1.3.7-alt1	asterisk = 1.3.7-alt1
asterisk-full#1.3.0-alt1	asterisk-devel-doc
asterisk-mysql#20060603:1.3.7-alt1	asterisk = 1.3.7-alt1
atanks#1.1.0-alt2	liballeg.so.4.1
autotrace#0.31.1-alt1.6.1	libMagick.so.9
avidemux#2.1.2-alt0.2	libx264.so.46
bos#1.1-alt1	/usr/games/stratagus
cinelerra#1.2.2-alt5	libavcodec.so
clanbomber#1.05-alt2	libHermes.so.1
clanlib#0.6.5-alt1.5	libHermes.so.1
clanlib-lua#0.6.5-alt1.5	liblua.so.4
clanlib-lua#0.6.5-alt1.5	liblualib.so.4
clanlib-lua#0.6.5-alt1.5	libtolua.so.4
dx#4.3.2-alt1.3	libMagick.so.9
epiphany-extensions#2.14.1.1-alt1	libosp.so.4
evolution-webcal#2.6.0-alt2	libecal-1.2.so.3
exim-ldap#4.60-alt1.1	libldap
f-spot#0.1.11-alt1	/usr/lib/f-spot/libfspoteog.so.0
f-spot#0.1.11-alt1	/usr/lib/f-spot/libfspotjpegtran.so.0
fatresize#1.0.2-alt4	libparted-1.6.so.13
fox-examples#1.6.0-alt0.1	libfox = 1.6.0-alt0.1
freeradius-ldap#1.0.4-alt1	liblber-2.2.so.7
freeradius-ldap#1.0.4-alt1	libldap_r-2.2.so.7
frontline#0.5.4-alt0.9.3	libMagick.so.9
galago-daemon#0.3.4-alt1	libdbus-1.so.1
galago-daemon#0.3.4-alt1	libdbus-glib-1.so.1
gdesklets#0.35.2-alt0.1	libgtop-2.0.so.5
glade#0.6.4-alt3	libbonobo.so.2
glade#0.6.4-alt3	libbonobox.so.2
glade#0.6.4-alt3	libgconf-1.so.1
glade#0.6.4-alt3	libgda >= 0.2.96
glade#0.6.4-alt3	libgda-client.so.0
glade#0.6.4-alt3	libgda-common.so.0
glade#0.6.4-alt3	libgnomeprint.so.15
gnofract4d#2.14-alt0.1	python2.4(_lsprof)
gnofract4d#2.14-alt0.1	python2.4(cProfile)
gnofract4d#2.14-alt0.1	python2.4(fractutils)
gnofract4d#2.14-alt0.1	python2.4(frm_docbook)
gnofract4d#2.14-alt0.1	python2.4(kid)
gnome-commander#1.1.6-alt2	fam
gnome-db#0.2.96-alt1.5	libbonobo.so.2
gnome-db#0.2.96-alt1.5	libbonobox.so.2
gnome-db#0.2.96-alt1.5	libgconf-1.so.1
gnome-db#0.2.96-alt1.5	libgda = 0.2.96
gnome-db#0.2.96-alt1.5	libgda-client.so.0
gnome-db#0.2.96-alt1.5	libgda-common.so.0
gnome-db#0.2.96-alt1.5	libgnomeprint.so.15
gnome-default-sisyphus#2.10.0-alt1	gnome2-games-glines >= 2.10.0
gnome-default-sisyphus#2.10.0-alt1	gnome2-games-mahjongg >= 2.10.0
gnome-default-sisyphus#2.10.0-alt1	gnome2-games-sol >= 2.10.0
gnome-minimal-sisyphus#2.10.0-alt1	gnome-applets-battstat >= 2.10.0
gnome-ppp#0.3.21-alt2	wvdial
gnomemeeting_1.2#1.2.2-alt1	libedataserver-1.2.so.4
gnomemeeting_1.2#1.2.2-alt1	liblber-2.2.so.7
gnomemeeting_1.2#1.2.2-alt1	libldap-2.2.so.7
gnugk#2.2.3-alt4	liblber-2.2.so.7
gnugk#2.2.3-alt4	libldap-2.2.so.7
gparted#0.2.5-alt3	libparted-1.7.so.0
gq#0.7.0-alt12.beta2	liblber-2.2.so.7
gq#0.7.0-alt12.beta2	libldap-2.2.so.7
gstreamer-cdio#0.8.11-alt4	libcdio.so.6(CDIO_6)
gstreamer-colorspace#0.8.11-alt4	libHermes.so.1
gstreamer-colorspace#0.8.11-alt4	libhermes >= 1.3.2
gstreamer-xvideosink#0.8.11-alt4	libhermes >= 1.3.2
gtk-engines-full#1:2.7.4-alt1	gtk-engines-qtcurve = 0.24.2-alt1
gtk-engines-full#1:2.7.4-alt1	gtk-engines-xfce = 2.2.1-alt1
gtk1-smooth-themes#0.5.2-alt1	gtk1-smooth-engine >= 0.5.2
hplip#0.9.4-alt3.1	libnetsnmp.so.9
hplip-sane#0.9.4-alt3.1	libnetsnmp.so.9
imapfilter#1.1.1-alt1	liblua.so.5
imapfilter#1.1.1-alt1	liblualib.so.5
install2-x11-qt#0.2.12-alt1	predator-kbd
kdar#2.0.6-alt1	libdar.so.3
kde-big#3.4-alt2	kmediagrab
kde-big#3.4-alt2	knetscan
kde-big#3.4-alt2	kover
kde-big#3.4-alt2	ktextdecode
kde-big#3.4-alt2	myldapklient
kde-big#3.4-alt2	noteedit
kde-distr#3.4-alt2	kde-icon-theme-lush
kde-maxi#3.4-alt2	ananas
kde-maxi#3.4-alt2	kde-icon-theme-lush
kde-maxi#3.4-alt2	kmediagrab
kde-maxi#3.4-alt2	knetscan
kde-maxi#3.4-alt2	kover
kde-maxi#3.4-alt2	ktextdecode
kde-maxi#3.4-alt2	myldapklient
kde-maxi#3.4-alt2	noteedit
kernel-complete-std26-up#2.6.14-alt3	kernel-modules-ndiswrapper-std26-up
kernel-modules-aksparlnx-std26-up#1.6-alt1.5	kernel-image-std26-up = 2.6.14-alt5
kernel-modules-amedyn-std26-up#20040801-alt6.132622.5	kernel-image-std26-up = 2.6.14-alt5
kernel-modules-amedyn-wks26-smp#20040801-alt6.132622.1	kernel-image-wks26-smp = 2.6.14-alt1
kernel-modules-amedyn-wks26-up#20040801-alt6.132622.5	kernel-image-wks26-up = 2.6.14-alt5
kernel-modules-ltmodem-vs26-smp#8.26a9-alt12.132624.3	kernel-image-vs26-smp = 2.6.16-alt3
kernel-modules-ltmodem-wks26-smp#8.26a9-alt12.132624.4	kernel-image-wks26-smp = 2.6.16-alt4
kernel-modules-ltmodem-wks26-up#8.26a9-alt12.132624.3	kernel-image-wks26-up = 2.6.16-alt3
kernel-modules-ndiswrapper-wks26-up#1.16-alt1.132624.3	kernel-image-wks26-up = 2.6.16-alt3
kernel-modules-unionfs-std26-smp#1.1.1-alt1.132622.5	kernel-image-std26-smp = 2.6.14-alt5
kernel-modules-unionfs-std26-up#1.1.1-alt1.132622.5	kernel-image-std26-up = 2.6.14-alt5
kernel-modules-unionfs-vs26-smp#1.1.1-alt1.132622.5	kernel-image-vs26-smp = 2.6.14-alt5
kernel-modules-unionfs-wks26-smp#1.1.1-alt1.132622.2	kernel-image-wks26-smp = 2.6.14-alt2
kernel-modules-unionfs-wks26-up#1.1.1-alt1.132622.5	kernel-image-wks26-up = 2.6.14-alt5
kernel-modules-zaptel-vs26-smp#1.3-alt10.132624.3	kernel-image-vs26-smp = 2.6.16-alt3
kguitar#0.5-alt2	libtse3
kguitar#0.5-alt2	libtse3.so.0
kiso#0.8.3-alt1	libcdio.so.6
kiso#0.8.3-alt1	libcdio.so.6(CDIO_6)
kiso#0.8.3-alt1	libiso9660.so.4
kiso#0.8.3-alt1	libiso9660.so.4(ISO9660_4)
koffice-krita#4:1.5.1-alt1	libMagick.so.9
labplot#1.5.0-alt0.4	libMagick++.so.9
labplot#1.5.0-alt0.4	libMagick.so.9
labplot#1.5.0-alt0.4	libWand.so.9
lamip-input-ape#0.0.2-alt0.1.20050227	libmac.so.2
libetpan#0.45-alt1	libgnutls.so.12(GNUTLS_1_2)
libevolution-sharp#0.10.2-alt2	libecal-1.2.so.3
libglade-gnomedb#0.17-alt9	libbonobo.so.2
libglade-gnomedb#0.17-alt9	libbonobox.so.2
libglade-gnomedb#0.17-alt9	libgconf-1.so.1
libglade-gnomedb#0.17-alt9	libgda-client.so.0
libglade-gnomedb#0.17-alt9	libgda-common.so.0
libglade-gnomedb#0.17-alt9	libgnomeprint.so.15
libgnome-db#0.2.96-alt1.5	libbonobo.so.2
libgnome-db#0.2.96-alt1.5	libbonobox.so.2
libgnome-db#0.2.96-alt1.5	libgconf-1.so.1
libgnome-db#0.2.96-alt1.5	libgda-client.so.0
libgnome-db#0.2.96-alt1.5	libgda-common.so.0
libgnome-db#0.2.96-alt1.5	libgnomeprint.so.15
libgnome-db-devel#0.2.96-alt1.5	libbonobo.so.2
libgnome-db-devel#0.2.96-alt1.5	libbonobox.so.2
libgnome-db-devel#0.2.96-alt1.5	libgconf-1.so.1
libgnome-db-devel#0.2.96-alt1.5	libgda-client.so.0
libgnome-db-devel#0.2.96-alt1.5	libgda-common.so.0
libgnome-db-devel#0.2.96-alt1.5	libgnomeprint.so.15
libgsf-sharp#0.6-alt1	libgsf-1.so.113
libgsf-sharp#0.6-alt1	libgsf-gnome-1.so.113
libhpoj#0.91-alt7.1	libsnmp.so.9
libofx#0.8.0-alt3	libosp.so.4
libopenh323_1.15#1.15.6-alt1	liblber-2.2.so.7
libopenh323_1.15#1.15.6-alt1	libldap-2.2.so.7
libopenh323_1.15#1.15.6-alt1	libldap_r-2.2.so.7
libopenh323_1.15-devel#1.15.6-alt1	liblber-2.2.so.7
libopenh323_1.15-devel#1.15.6-alt1	libldap-2.2.so.7
libopenh323_1.15-devel#1.15.6-alt1	libldap_r-2.2.so.7
libopensc#0.8.1-alt4.1.1	liblber-2.2.so.7
libopensc#0.8.1-alt4.1.1	libldap-2.2.so.7
libopensync-plugin-evolution2#0.18-alt4cvs20060529	libecal-1.2.so.3
libopensync-plugin-python#0.18-alt2cvs20060529	python2.4(opensync)
libpw_1.8#1.8.7-alt1	liblber-2.2.so.7
libpw_1.8#1.8.7-alt1	libldap-2.2.so.7
libpw_1.8#1.8.7-alt1	libldap_r-2.2.so.7
libpw_1.8-plugins-dc#1.8.7-alt1	libdc1394_control.so.13
libq#6.2-alt1.1	libgg.so.0
libq#6.2-alt1.1	libggi.so.2
libq#6.2-alt1.1	libgii.so.0
libquicktime-ffmpeg#0.9.8-alt4	libavcodec.so
libquicktime-ffmpeg#0.9.8-alt4	libavutil.so
libquicktimehv#2.0.4-alt5	libavcodec.so
libsmbclient#3.0.21c-alt1	liblber-2.2.so.7
libsmbclient#3.0.21c-alt1	libldap-2.2.so.7
lighttpd#1.4.9-alt1	liblber-2.2.so.7
lighttpd#1.4.9-alt1	libldap-2.2.so.7
lighttpd-cml#1.4.9-alt1	liblua.so.5
lighttpd-cml#1.4.9-alt1	liblualib.so.5
liquidwar#5.6.2-alt1	liballeg.so.4.1
lua5-rex#1.19-alt1	liblua.so.5
lua5-rex#1.19-alt1	liblualib.so.5
lve#050112-alt0.1	libavcodec.so
lve#050112-alt0.1	libavformat.so
lyx-xforms#1.3.7-alt1	lyx-common = 1.3.7-alt1
mailman#4:2.1.8-alt1	python2.4(Defaults)
mailman#4:2.1.8-alt1	python2.4(Mailman)
mailman#4:2.1.8-alt1	python2.4(japanese)
mailman#4:2.1.8-alt1	python2.4(korean)
mailman#4:2.1.8-alt1	python2.4(mm_config)
mbrowse#0.3.1-alt5.1	libnetsnmp.so.9
midgard-data#1.5.1-alt0.3cvs20030916	php-midgard
motion#3.2.4-alt1	libavcodec.so
motion#3.2.4-alt1	libavformat.so
mozilla-be#1.7.12-alt1.3	mozilla = 1.7.12-alt3.4
mozilla-uk#1.7.12-alt1.3	mozilla = 1.7.12-alt3.3
mrsync#3.1.1-alt0.1	libmrsync = 3.1.1-alt0.1
multisync-ldap#0.82-alt1.1.1	libldap-2.2.so.7
ocaml-wlex#20030929-alt7.1	camlp4 = 3.08.1-alt1.1
ocaml-wlex#20030929-alt7.1	ocaml = 3.08.1-alt1.1
ocamlnet#0.98-alt1.1	ocaml = 3.08.1-alt1.1
ocamlnet#0.98-alt1.1	pcre-ocaml = 5.09.0-alt1.1
ocamlnet-runtime#0.98-alt1.1	ocaml-runtime = 3.08.1-alt1.1
oxine#0.5-alt2	libMagick.so.9
partitionmorpher#0.3-alt8	libparted-1.6.so.13
pentaval-tools#2.1.10-alt1	kernel-modules-pentaval
perl-Module-Signature#0.50-alt1	perl(PAR/Dist.pm)
perl-SOAP-Lite#0.67-alt1	perl(DIME/Message.pm)
perl-SOAP-Lite#0.67-alt1	perl(DIME/Payload.pm)
php-ldap#1:4.4.2-alt0.cvs20051121.1	liblber-2.2.so.7
php-ldap#1:4.4.2-alt0.cvs20051121.1	libldap-2.2.so.7
php-mmcache#1:2.4.6-alt9.1	php-libs = 1:4.4.1-alt0.cvs20051010
php-snmp#1:4.4.2-alt0.cvs20051121.1	libnetsnmp.so.9
php5-ldap#5.1.3.cvs20060122-alt1	liblber-2.2.so.7
php5-ldap#5.1.3.cvs20060122-alt1	libldap-2.2.so.7
pingus#0.6.0-alt7	libhermes
python-ctypes-doc#0.9.6-alt2	python-ctypes = 0.9.6
python-module-FormEncode#0.4-alt2.1	python2.4(formencode)
python-module-MMTK#2.5.13-alt1	python2.4(MMTK_energy_term)
python-module-SQLObject#0.7rc1-alt1	python2.4(formencode)
python-module-ldap#2.2.0-alt1.1	libldap
python-module-matplotlib#0.87.2-alt0.1	python2.4(AppKit)
python-module-matplotlib#0.87.2-alt0.1	python2.4(Foundation)
python-module-matplotlib#0.87.2-alt0.1	python2.4(PyObjCTools)
python-module-matplotlib#0.87.2-alt0.1	python2.4(numarray)
python-module-matplotlib#0.87.2-alt0.1	python2.4(numpy)
python-module-matplotlib#0.87.2-alt0.1	python2.4(paint)
python-module-pyzor#0.4.0-alt1	python2.4(pyzor)
python-module-samba#3.0.21c-alt1	liblber-2.2.so.7
python-module-samba#3.0.21c-alt1	libldap-2.2.so.7
python-musicbrainz-doc#1.0b3-alt1	python-musicbrainz = 1.0b3
rox-system#1.9.0-alt1	libgtop-2.0.so.5
samba#3.0.21c-alt1	liblber-2.2.so.7
samba#3.0.21c-alt1	libldap-2.2.so.7
samba-client#3.0.21c-alt1	liblber-2.2.so.7
samba-client#3.0.21c-alt1	libldap-2.2.so.7
samba-common#3.0.21c-alt1	liblber-2.2.so.7
samba-common#3.0.21c-alt1	libldap-2.2.so.7
samba-swat#3.0.21c-alt1	liblber-2.2.so.7
samba-swat#3.0.21c-alt1	libldap-2.2.so.7
samba-utils#3.0.21c-alt1	liblber-2.2.so.7
samba-utils#3.0.21c-alt1	libldap-2.2.so.7
snort#2.4.3-alt1.1	libprelude
snort-snmp#2.4.3-alt1.1	libnetsnmp.so.9
snort-snmp+flexresp#2.4.3-alt1.1	libnetsnmp.so.9
sylpheed-claws-plugin-dillo#2.2.0.cvs66-alt1	dillo
thoggen#0.3.1-alt4.1	libdbus-1.so.1
thoggen#0.3.1-alt4.1	libdbus-glib-1.so.1
tolua5#5.0-alt2a	liblua.so.5
tolua5#5.0-alt2a	liblualib.so.5
trac-fcgi#0.9.4-alt1	trac-spawn-fcgi
trophy#1.1.3-alt4.1	libHermes.so.1
twinkle#0.7.1-alt0.1	libresolv.so.2(GLIBC_PRIVATE)
vdr-dvd#0.3.6_b03-alt1	libdvdnav.so.0
vdr-osdpip#0.0.7.1-alt3	libavcodec.so
vlc#0.8.6-alt0.15786	libdvbpsi.so.1
vlc-plugin-dvb#0.8.6-alt0.15786	libdvbpsi.so.1
vlc-plugin-ts#0.8.6-alt0.15786	libdvbpsi.so.1
wmforkplop#0.9.2-alt1	libgtop-2.0.so.5
xalan-c#1.10.0-alt2	libxalanMsg.so
xalan-j-manual#2.7.0-alt2	javadoc = 2.7.0-alt2
xfce4-complete#1.0-alt1	xfce4-netload-plugin
xmms-full#0.1-alt2	xmms-in-mac
xmms-full#0.1-alt2	xmms-vis-gdancer
xmms-full#0.1-alt2	xmms-vis-scivi
zabbix-mysql#1.1rel-alt1	libnetsnmp.so.9

Из них следующее unmet'ы существуют уже не менее двух месяцев.

apt-indicator#0.0.4-alt7	libapt-pkg-libc6.3-6.so.0
fox-examples#1.6.0-alt0.1	libfox = 1.6.0-alt0.1
gdesklets#0.35.2-alt0.1	libgtop-2.0.so.5
gnome-minimal-sisyphus#2.10.0-alt1	gnome-applets-battstat >= 2.10.0
gnomemeeting_1.2#1.2.2-alt1	libedataserver-1.2.so.4
gtk-engines-full#1:2.7.4-alt1	gtk-engines-qtcurve = 0.24.2-alt1
kde-big#3.4-alt2	kover
kde-big#3.4-alt2	myldapklient
kde-big#3.4-alt2	noteedit
kde-distr#3.4-alt2	kde-icon-theme-lush
kde-maxi#3.4-alt2	ananas
kde-maxi#3.4-alt2	kde-icon-theme-lush
kde-maxi#3.4-alt2	kover
kde-maxi#3.4-alt2	myldapklient
kde-maxi#3.4-alt2	noteedit
kernel-modules-aksparlnx-std26-up#1.6-alt1.5	kernel-image-std26-up = 2.6.14-alt5
kernel-modules-amedyn-std26-up#20040801-alt6.132622.5	kernel-image-std26-up = 2.6.14-alt5
kernel-modules-amedyn-wks26-smp#20040801-alt6.132622.1	kernel-image-wks26-smp = 2.6.14-alt1
kernel-modules-unionfs-std26-smp#1.1.1-alt1.132622.5	kernel-image-std26-smp = 2.6.14-alt5
kernel-modules-unionfs-std26-up#1.1.1-alt1.132622.5	kernel-image-std26-up = 2.6.14-alt5
lamip-input-ape#0.0.2-alt0.1.20050227	libmac.so.2
libgsf-sharp#0.6-alt1	libgsf-1.so.113
libgsf-sharp#0.6-alt1	libgsf-gnome-1.so.113
libq#6.2-alt1.1	libgg.so.0
libq#6.2-alt1.1	libggi.so.2
libq#6.2-alt1.1	libgii.so.0
midgard-data#1.5.1-alt0.3cvs20030916	php-midgard
mozilla-be#1.7.12-alt1.3	mozilla = 1.7.12-alt3.4
mozilla-uk#1.7.12-alt1.3	mozilla = 1.7.12-alt3.3
ocaml-wlex#20030929-alt7.1	camlp4 = 3.08.1-alt1.1
ocaml-wlex#20030929-alt7.1	ocaml = 3.08.1-alt1.1
ocamlnet#0.98-alt1.1	ocaml = 3.08.1-alt1.1
ocamlnet#0.98-alt1.1	pcre-ocaml = 5.09.0-alt1.1
ocamlnet-runtime#0.98-alt1.1	ocaml-runtime = 3.08.1-alt1.1
perl-Module-Signature#0.50-alt1	perl(PAR/Dist.pm)
perl-SOAP-Lite#0.67-alt1	perl(DIME/Message.pm)
perl-SOAP-Lite#0.67-alt1	perl(DIME/Payload.pm)
php-mmcache#1:2.4.6-alt9.1	php-libs = 1:4.4.1-alt0.cvs20051010
python-ctypes-doc#0.9.6-alt2	python-ctypes = 0.9.6
python-module-FormEncode#0.4-alt2.1	python2.4(formencode)
python-module-SQLObject#0.7rc1-alt1	python2.4(formencode)
python-module-pyzor#0.4.0-alt1	python2.4(pyzor)
python-musicbrainz-doc#1.0b3-alt1	python-musicbrainz = 1.0b3
rox-system#1.9.0-alt1	libgtop-2.0.so.5
vdr-dvd#0.3.6_b03-alt1	libdvdnav.so.0
wmforkplop#0.9.2-alt1	libgtop-2.0.so.5
xalan-c#1.10.0-alt2	libxalanMsg.so
xalan-j-manual#2.7.0-alt2	javadoc = 2.7.0-alt2
xmms-full#0.1-alt2	xmms-in-mac
xmms-full#0.1-alt2	xmms-vis-gdancer
xmms-full#0.1-alt2	xmms-vis-scivi

Часть анметов таковыми не является, потому что rpm эти пакеты нормально ставит.
Апт не понимает одной тонкости в зависимостях, которая связана с путями.

[at@basalt RPMS]$ rpm -qpR f-spot-0.1.11-alt1.i586.rpm |grep /lib
/usr/lib/f-spot/libfspoteog.so.0  
/usr/lib/f-spot/libfspotjpegtran.so.0  
[at@basalt RPMS]$ rpm -iv --test f-spot-0.1.11-alt1.i586.rpm
Preparing packages for installation...
[at@basalt RPMS]$ 

Предлагаю в связи с этим зафиксить apt.  Кто знает, как фиксить apt?

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

[devel] libldap22? (was: full list of unmets)

[Michael Shigorin]

On Mon, Jun 19, 2006 at 05:06:37AM +0400, Alexey Tourbin wrote:
> LDAPExplorerTool#0.6-alt0.1	liblber-2.2.so.7
> LDAPExplorerTool#0.6-alt0.1	libldap-2.2.so.7

Насколько понимаю, не всё пересобралось без рукоприкладства?
Имеет ли смысл собрать libldap22 или как раз только что и
говорили, что нафиг-нафиг?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] full list of unmets

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [060619 05:08]:
> Робот, который отслеживает unmet'ы, был запущен ровно год назад.
Теоретически, часть анметов можно разруливать на автомате:

Группируем unmet'ы по %{SOURCERPM}.  Пересобираем этот пакет.
Если после пересборки все эти unmet'ы пропали, пинаем qa-робота
на пересборку "with new $(diff -U0 requires.old requires.new |
grep '^+')".  Это решает автоматические пересборки с новым
SONAME, пересборку модулей php или firefox extensions и так
далее.

Да можно даже не напрягать робота-пересборщика (которого нет), а
просто говорить, что такие пакеты могут быть _пересобраны_.

-- 
Regards,
Sir Raorn.

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

Re: [devel] full list of unmets

[Led]

В сообщении от 19 июня 2006 04:06 Alexey Tourbin написал(a):
> Вот полный список unmet'ов.
...........
> gparted#0.2.5-alt3	libparted-1.7.so.0
............

Прошу помощи в выпуске gparted#0.2.5-alt4.
Конкретнее: помогите придумать запись в %changelog для alt4, потому как кроме

- fucking rebuild cause fucking random queue in incoming!

ничего в голову не приходит :(

-- 
Led.

Re: [devel] full list of unmets

[Epiphanov Sergei]

В сообщении от Monday 19 June 2006 13:38 Led написал(a):
> В сообщении от 19 июня 2006 04:06 Alexey Tourbin написал(a):
> Прошу помощи в выпуске gparted#0.2.5-alt4.
> Конкретнее: помогите придумать запись в %changelog для alt4, потому как
> кроме

- rebuild only to fix unmets

?

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

Re: [devel] full list of unmets

[Kirill Maslinsky]

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

> > Вот полный список unmet'ов.
> ...........
> > gparted#0.2.5-alt3	libparted-1.7.so.0
> ............
> 
> Прошу помощи в выпуске gparted#0.2.5-alt4.
> Конкретнее: помогите придумать запись в %changelog для alt4, потому как кроме
> 
> - fucking rebuild cause fucking random queue in incoming!
Наверное, правильнее будет написать так:
  - f####ng rebuild caused by f####ng random queue in incoming

:)

-- 
Kirill Maslinsky
ALT Linux Documentation Team

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

Re: [devel] full list of unmets

[Anton Farygin]

Led wrote:
> В сообщении от 19 июня 2006 04:06 Alexey Tourbin написал(a):
>> Вот полный список unmet'ов.
> ...........
>> gparted#0.2.5-alt3	libparted-1.7.so.0
> ............
> 
> Прошу помощи в выпуске gparted#0.2.5-alt4.
> Конкретнее: помогите придумать запись в %changelog для alt4, потому как кроме
> 
> - fucking rebuild cause fucking random queue in incoming!
> 
> ничего в голову не приходит :(
> 

rebuild без изменений

Re: [devel] full list of unmets

[Michael Shigorin]

On Mon, Jun 19, 2006 at 12:38:16PM +0300, Led wrote:
> Прошу помощи в выпуске gparted#0.2.5-alt4.
> Конкретнее: помогите придумать запись в %changelog для alt4

- rebuild

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] full list of unmets

[Led]

В сообщении от 19 июня 2006 13:11 Michael Shigorin написал(a):
> On Mon, Jun 19, 2006 at 12:38:16PM +0300, Led wrote:
> > Прошу помощи в выпуске gparted#0.2.5-alt4.
> > Конкретнее: помогите придумать запись в %changelog для alt4
>
> - rebuild

Всем спасибо за совет, честно:)

Хотя всё же мне не совсем понятна цель тестовых пересборок, если результат из 
не попадает в репозитарий. Тем более, что уведомления о "неуспешной" 
пересборке именно gparted не было: оно и понятно - он сразу же 
успешно "пересобрался"...

-- 
Led.

Re: [devel] full list of unmets

[Michael Shigorin]

On Mon, Jun 19, 2006 at 01:22:49PM +0300, Led wrote:
> Хотя всё же мне не совсем понятна цель тестовых пересборок,
> если результат из не попадает в репозитарий.

Работает -- не трогай.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] full list of unmets

[Led]

В сообщении от 19 июня 2006 15:28 Michael Shigorin написал(a):
> On Mon, Jun 19, 2006 at 01:22:49PM +0300, Led wrote:
> > Хотя всё же мне не совсем понятна цель тестовых пересборок,
> > если результат из не попадает в репозитарий.
>
> Работает -- не трогай.

Дык, в данном случае, как раз "НЕ работает":)

-- 
Led.

Re: [devel] full list of unmets

[Igor Vlasenko]

On Mon, 19 Jun 2006, Alexey Tourbin wrote:
> Робот, который отслеживает unmet'ы, был запущен ровно год назад.
> С тех пор количество unmet'ов значительно возросло:
> Вот полный список unmet'ов.

Спасибо большое за список, 
по своему опыту хочу высказать назревшее пожелание:

Было бы идеально модифицировать робот, 
добавив пару строчек, чтобы тот автоматически где-то публиковал в сети
full list of unmets (хотя бы в текстовом виде), хотя бы в /people.

Я вот посмотрел full list и увидел пару неожиданных unmets на ffmpeg.
Притом что я внимательно читаю рассылку ---
проблемы с почтовым сервером :( 
чужой сервер, чужой спамфилтер.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] full list of unmets

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 1030 bytes --]

On Mon, Jun 19, 2006 at 02:44:41PM +0300, Igor Vlasenko wrote:
> On Mon, 19 Jun 2006, Alexey Tourbin wrote:
> > Робот, который отслеживает unmet'ы, был запущен ровно год назад.
> > С тех пор количество unmet'ов значительно возросло:
> > Вот полный список unmet'ов.
> 
> Спасибо большое за список, 
> по своему опыту хочу высказать назревшее пожелание:
> 
> Было бы идеально модифицировать робот, 
> добавив пару строчек, чтобы тот автоматически где-то публиковал в сети
> full list of unmets (хотя бы в текстовом виде), хотя бы в /people.
> 
> Я вот посмотрел full list и увидел пару неожиданных unmets на ffmpeg.
> Притом что я внимательно читаю рассылку ---
> проблемы с почтовым сервером :( 
> чужой сервер, чужой спамфилтер.

Можно время от времени закидывать full list of unmets в sisyphus-cybertalk.

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

[-- Attachment #1.2: dump.log.gz --]
[-- Type: application/x-gzip, Size: 11402 bytes --]

[-- Attachment #1.3: dump.old.gz --]
[-- Type: application/x-gzip, Size: 3414 bytes --]

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

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Mon, Jun 19, 2006 at 07:45:17PM +0400, Alexey Tourbin wrote:
> Можно время от времени закидывать full list of unmets в sisyphus-cybertalk.
> 
> Вот задача на пару трубок.  Имеется полный список список анметов и
> инкрементный лог их появления (прицеплено).  Требуется к каждому анмету
> проставить время (в неделях), которое этот анмет существует.

Элегантное решение существует.  Стоимость элегантного решения прмерно $481.

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

Re: [devel] full list of unmets

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [060619 22:24]:
> > Вот задача на пару трубок.  Имеется полный список список анметов и
> > инкрементный лог их появления (прицеплено).  Требуется к каждому анмету
> > проставить время (в неделях), которое этот анмет существует.
> Элегантное решение существует.  Стоимость элегантного решения прмерно $481.
Как обычно по доллару за байт? ;-)

-- 
Regards,
Sir Raorn.

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

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Tue, Jun 20, 2006 at 12:06:08AM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [060619 22:24]:
> > > Вот задача на пару трубок.  Имеется полный список список анметов и
> > > инкрементный лог их появления (прицеплено).  Требуется к каждому анмету
> > > проставить время (в неделях), которое этот анмет существует.
> > Элегантное решение существует.  Стоимость элегантного решения прмерно $481.
> Как обычно по доллару за байт? ;-)

Да.  Элегантные программы наверное того стоят. :-)  Правда,
в большинстве случаев нельзя определить, является ли программа
элегантной (т.е. наиболее элегантной в своем роде).

Theorem (Chaitin): It is not possible in general to determine whether
or not a given program is elegant.

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

Re: [devel] full list of unmets

[Damir Shayhutdinov]

19.06.06, Alexey Tourbin<at@altlinux.ru> написал(а):
> On Mon, Jun 19, 2006 at 07:45:17PM +0400, Alexey Tourbin wrote:
> > Можно время от времени закидывать full list of unmets в sisyphus-cybertalk.
> >
> > Вот задача на пару трубок.  Имеется полный список список анметов и
> > инкрементный лог их появления (прицеплено).  Требуется к каждому анмету
> > проставить время (в неделях), которое этот анмет существует.
>
> Элегантное решение существует.  Стоимость элегантного решения прмерно $481.
Зипованные доллары принимаете?

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Tue, Jun 20, 2006 at 12:13:44AM +0400, Damir Shayhutdinov wrote:
> 19.06.06, Alexey Tourbin<at@altlinux.ru> написал(а):
> > On Mon, Jun 19, 2006 at 07:45:17PM +0400, Alexey Tourbin wrote:
> > > Можно время от времени закидывать full list of unmets в sisyphus-cybertalk.
> > >
> > > Вот задача на пару трубок.  Имеется полный список список анметов и
> > > инкрементный лог их появления (прицеплено).  Требуется к каждому анмету
> > > проставить время (в неделях), которое этот анмет существует.
> >
> > Элегантное решение существует.  Стоимость элегантного решения прмерно $481.
> Зипованные доллары принимаете?

Зип хорошо жмет от $1000.

$ wc -c <full_unmets
972
$ gzip <full_unmets |wc -c
554
$

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

Re: [devel] [JT] full list of unmets

[Ivan Fedorov]

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

Alexey Tourbin пишет:
>>> Элегантное решение существует.  Стоимость элегантного решения прмерно $481.
>> Зипованные доллары принимаете?
> 
> Зип хорошо жмет от $1000.
> 
> $ wc -c <full_unmets
> 972
> $ gzip <full_unmets |wc -c
> 554
> $

А что говорит zme ? :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Mon, Jun 19, 2006 at 05:06:37AM +0400, Alexey Tourbin wrote:
> Минимальным значение unmet'ов было в марте.
> 
> Date: Sun, 26 Mar 2006 05:08:19 +0400
> Subject: [Sisyphus-cybertalk] I: Sisyphus-20060326 i586 unmets: -3 (82/67)

Ещё меньше анметов было в феврале.

Date: Mon, 20 Feb 2006 21:08:18 +0300
Subject: [Sisyphus-cybertalk] I: Sisyphus-20060220 i586 unmets: -4 (57/50)

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

Я также сомневаюсь, что удастся найти "волшебный" алгоритм, который
блокирует анметы на входе.  Например, вчера в сизиф прошла новая версия
firefox.  Часть плагинов была пересобрана с новой версией firefox, тогда
как другая часть не была пересобрана.  Может быть эти пакеты просто
забыли автоматически пересобрать?  От incoming/incominger'а по этому
поводу ничего не слышно.

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

Короче, у меня два вопроса по поводу вчерашнего firefox:

1) почему робот автоматически не пересобрал все остальные плагины?
в результате количество анметов увеличилось более чем на 20.

2) почему плагины так жестко зависят от версии firefox, так что их даже
приходится пересобирать при sub-micro изменении версии, очевидно
багфиксной?  Кто и зачем придумал такие жесткие зависимости?

А на x86_64 анметов вообще 700 штук.  Будет у нас Фриз, Бранч или
Херанч, или не будет, в общем-то ясно, что от проблемы анметов никуда
не уйти.  По-моему до "ловли блох" ещё далеко (и пока нет веских
оснований думать, что к зиме будет ближе).

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

Re: [devel] full list of unmets

[Dmitry V. Levin]

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

On Tue, Jun 20, 2006 at 04:04:10AM +0400, Alexey Tourbin wrote:
> Я также сомневаюсь, что удастся найти "волшебный" алгоритм, который
> блокирует анметы на входе.  Например, вчера в сизиф прошла новая версия
> firefox.  Часть плагинов была пересобрана с новой версией firefox, тогда
> как другая часть не была пересобрана.  Может быть эти пакеты просто
> забыли автоматически пересобрать?  От incoming/incominger'а по этому
> поводу ничего не слышно.

Я не знаю, существует ли этот "волшебный" алгоритм.
Но у меня есть такое наблюдение: среди множества пакетов, приходящих в
течение суток в /i/S, всегда есть такие, которые не порождают новых
unmet'ов.  Я думаю, что выявлять такие пакеты теперь, когда Legion по моей
просьбе написал оптимизированную замену genpkglist, можно быстро и дёшево.
Я полагаю, что для начала нужно обеспечить быстрое (автоматическое, без
участия человека вообще) прохождение этих пакетов из /i/S в Sisyphus.
Я удивляюсь тому факту, что это ещё не реализовано.

> А на x86_64 анметов вообще 700 штук.  Будет у нас Фриз, Бранч или
> Херанч, или не будет, в общем-то ясно, что от проблемы анметов никуда
> не уйти.  По-моему до "ловли блох" ещё далеко (и пока нет веских
> оснований думать, что к зиме будет ближе).

Должен отметить, что меня как пользователя Сизифа эти unmet'ы не волнуют,
ибо они меня как пользователя Сизифа просто не затрагивают.

Иногда мне кажется, что я единственный пользователь Сизифа, и в такие
моменты мне хочется просто удалить все пакеты с unmet'ами, а также все
несобирающиеся пакеты, и ещё некоторое количество пакетов, которые мне
просто не нравятся.  Хорошо, что это быстро проходит. :)

Кстати, если с волшебными алгоритмами ничего не выйдет, может просто
выделить небольшое подмножество Сизифа, которое будет гарантированно
замкнутым (например, как Owl)?


-- 
ldv

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

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Tue, Jun 20, 2006 at 04:17:25AM +0400, Dmitry V. Levin wrote:
> On Tue, Jun 20, 2006 at 04:04:10AM +0400, Alexey Tourbin wrote:
> > Я также сомневаюсь, что удастся найти "волшебный" алгоритм, который
> > блокирует анметы на входе.  Например, вчера в сизиф прошла новая версия
> > firefox.  Часть плагинов была пересобрана с новой версией firefox, тогда
> > как другая часть не была пересобрана.  Может быть эти пакеты просто
> > забыли автоматически пересобрать?  От incoming/incominger'а по этому
> > поводу ничего не слышно.
> 
> Я не знаю, существует ли этот "волшебный" алгоритм.

Существуют лишь относительно "волшебные" алгоритмы.  Абсолютно
волшебного алгоритма в данном случае не существует прежде всего из
соображений falsifiability (по Попперу).  То есть нельзя из чего угодно
сделать конфетку.  Хороший алгоритм просто откажется что-либо пропускать
из остойника в сизиф, а это "не даст ничего нового", потому что и так
можно ничего не пропускать, ровно без всякого алгоритма. :)

> Но у меня есть такое наблюдение: среди множества пакетов, приходящих в
> течение суток в /i/S, всегда есть такие, которые не порождают новых
> unmet'ов.  Я думаю, что выявлять такие пакеты теперь, когда Legion по моей
> просьбе написал оптимизированную замену genpkglist, можно быстро и дёшево.
> Я полагаю, что для начала нужно обеспечить быстрое (автоматическое, без
> участия человека вообще) прохождение этих пакетов из /i/S в Sisyphus.
> Я удивляюсь тому факту, что это ещё не реализовано.

Некоторые трудности реализации обсуждались в соседних тредах.  
В общем случае это не так-то просто реализовать.  Может быть можно
выделать некоторые частные случаи и отдать их на откуп автоматике.

В простейшем случае есть сизиф и есть отсойник (оверлей, типа RPMS.hasher).
Все входящие пакеты собираются в отстойнике.  Если какой-либо пакет
1) при сборке не зацепил в сборочную среду каких-либо пакетов из
отстойника 2) не порождает новых анметов ни в сизифе, ни в отстойнике
тогда этот пакет можно автоматически без каких-либо опасений перемещать
в сизиф.

Первый пункт гарантирует то, что пакет пакета на сизифе (без отстойника)
будет идентичной.

Второй пункт требует пояснений.  Вообще говоря, НЕЛЬЗЯ проверять
количество анметов по оверлею из aptbox'а.  Нужно полностью сформировать
переходный репозитарий, удалить ошметки собранных пакетов при помощи
sisyphus_unpaired и проверять анметы уже по нему.  Это выявляет
хаки по маскировке анметов, типа libldap->libldap2.3 или
lublua5->liblua5.1.

> > А на x86_64 анметов вообще 700 штук.  Будет у нас Фриз, Бранч или
> > Херанч, или не будет, в общем-то ясно, что от проблемы анметов никуда
> > не уйти.  По-моему до "ловли блох" ещё далеко (и пока нет веских
> > оснований думать, что к зиме будет ближе).
> 
> Должен отметить, что меня как пользователя Сизифа эти unmet'ы не волнуют,
> ибо они меня как пользователя Сизифа просто не затрагивают.
> 
> Иногда мне кажется, что я единственный пользователь Сизифа, и в такие
> моменты мне хочется просто удалить все пакеты с unmet'ами, а также все
> несобирающиеся пакеты, и ещё некоторое количество пакетов, которые мне
> просто не нравятся.  Хорошо, что это быстро проходит. :)
> 
> Кстати, если с волшебными алгоритмами ничего не выйдет, может просто
> выделить небольшое подмножество Сизифа, которое будет гарантированно
> замкнутым (например, как Owl)?

Я тоже пользуюсь весьма ограниченным набором пакетов из сизифа.
И всё же если бы набор этих пакетов был совсем уж ограниченным, тогда
есть повод совсем пересесть на Owl.

То есть приходится не только воспринимать себя "как пользователя Сизифа",
но и как разработчика сизифа, причем не сугубо как maintainer'а отдельных
пакетов.

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

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Tue, Jun 20, 2006 at 04:55:01AM +0400, Alexey Tourbin wrote:
> В простейшем случае есть сизиф и есть отсойник (оверлей, типа RPMS.hasher).
> Все входящие пакеты собираются в отстойнике.  Если какой-либо пакет
> 1) при сборке не зацепил в сборочную среду каких-либо пакетов из
> отстойника 2) не порождает новых анметов ни в сизифе, ни в отстойнике
> тогда этот пакет можно автоматически без каких-либо опасений перемещать
> в сизиф.
> 
> Первый пункт гарантирует то, что пакет пакета на сизифе (без отстойника)
> будет идентичной.

"Что _сборка_ пакета на сизифе без отстойника будет идентичной."

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

Re: [devel] full list of unmets

[Dmitry V. Levin]

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

On Tue, Jun 20, 2006 at 04:55:01AM +0400, Alexey Tourbin wrote:
> On Tue, Jun 20, 2006 at 04:17:25AM +0400, Dmitry V. Levin wrote:
> > On Tue, Jun 20, 2006 at 04:04:10AM +0400, Alexey Tourbin wrote:
> > > Я также сомневаюсь, что удастся найти "волшебный" алгоритм, который
> > > блокирует анметы на входе.  Например, вчера в сизиф прошла новая версия
> > > firefox.  Часть плагинов была пересобрана с новой версией firefox, тогда
> > > как другая часть не была пересобрана.  Может быть эти пакеты просто
> > > забыли автоматически пересобрать?  От incoming/incominger'а по этому
> > > поводу ничего не слышно.
> > 
> > Я не знаю, существует ли этот "волшебный" алгоритм.
> 
> Существуют лишь относительно "волшебные" алгоритмы.  Абсолютно
> волшебного алгоритма в данном случае не существует прежде всего из
> соображений falsifiability (по Попперу).  То есть нельзя из чего угодно
> сделать конфетку.  Хороший алгоритм просто откажется что-либо пропускать
> из остойника в сизиф, а это "не даст ничего нового", потому что и так
> можно ничего не пропускать, ровно без всякого алгоритма. :)

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

> В простейшем случае есть сизиф и есть отсойник (оверлей, типа RPMS.hasher).

В простейшем случае нет отстойника.
Например, каждый новый пакет, будучи собранным, образует новый репозиторий
Sisyphus, состоящий из всех прежних пакетов минус пакеты, собранные из
прежней версии (если были) плюс свежесобранные пакеты.
Если в этом репозитории unmet'ов не прибавилось по сравнению с
первоначальным Сизифом, то свежесобранный пакет можно спокойно пропускать,
а свежесформированный репозиторий использовать дальше для сборки.
Если нет, то пакет требует более сложной обработки, а свежесформированный
репозиторий откатывается на прежний.
Я голословно утверждаю, что не менее половины пакетов, приходящих в /i/S,
могут быть обработаны таким простым способом.
При наличии оптимизированной замены genpkglist формирование нового
временного репозитория Sisyphus должно происходить существенно быстрее,
чем сборка среднего пакета.

Что касается более сложной обработки, то тут надо вспомнить математику и
хорошенько подумать.


-- 
ldv

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

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
> В простейшем случае нет отстойника.
> Например, каждый новый пакет, будучи собранным, образует новый репозиторий
> Sisyphus, состоящий из всех прежних пакетов минус пакеты, собранные из
> прежней версии (если были) плюс свежесобранные пакеты.

Что значит "плюс свежесобранные пакеты"?

Вот идут подряд пакеты A и B.  Пакет B сборочно-завист от A.  Пакет A не
удовлетворяет простому алгоритму (т.е. откладывается в "отстойник" --
решение будет приниматься вручную).  Тогда сборки пакета B на-сизифе и
на-отстойнике в общем случае не идентичны.  Где собирать пакет B?

В идеале нельзя собирать пакет B раньше, чем будет принято решение
по пакету A.  Это особенно важно, если пакеты A и B пришли от одного
maintainer'а, потому что maintiner таким образом может рассчитывать,
что пакет B будет собран именно с этим пакетом A.

> Если в этом репозитории unmet'ов не прибавилось по сравнению с
> первоначальным Сизифом, то свежесобранный пакет можно спокойно пропускать,
> а свежесформированный репозиторий использовать дальше для сборки.
> Если нет, то пакет требует более сложной обработки, а свежесформированный
> репозиторий откатывается на прежний.
> Я голословно утверждаю, что не менее половины пакетов, приходящих в /i/S,
> могут быть обработаны таким простым способом.
> При наличии оптимизированной замены genpkglist формирование нового
> временного репозитория Sisyphus должно происходить существенно быстрее,
> чем сборка среднего пакета.
> 
> Что касается более сложной обработки, то тут надо вспомнить математику и
> хорошенько подумать.

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

Re: [devel] full list of unmets

[Dmitry V. Levin]

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

On Tue, Jun 20, 2006 at 05:32:01AM +0400, Alexey Tourbin wrote:
> On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
> > В простейшем случае нет отстойника.
> > Например, каждый новый пакет, будучи собранным, образует новый репозиторий
> > Sisyphus, состоящий из всех прежних пакетов минус пакеты, собранные из
> > прежней версии (если были) плюс свежесобранные пакеты.
> 
> Что значит "плюс свежесобранные пакеты"?
> 
> Вот идут подряд пакеты A и B.  Пакет B сборочно-завист от A.  Пакет A не
> удовлетворяет простому алгоритму (т.е. откладывается в "отстойник" --
> решение будет приниматься вручную).  Тогда сборки пакета B на-сизифе и
> на-отстойнике в общем случае не идентичны.  Где собирать пакет B?
> 
> В идеале нельзя собирать пакет B раньше, чем будет принято решение
> по пакету A.  Это особенно важно, если пакеты A и B пришли от одного
> maintainer'а, потому что maintiner таким образом может рассчитывать,
> что пакет B будет собран именно с этим пакетом A.

Я всё же думаю, что в описанной ситуации пакет B следует собирать без учёта
пакета A.  Обоснование простое и состоит из двух частей:
1. Мантейнер может и должен позаботиться о том, чтобы пакет A не попал в
отстойник.  В частности, если имеет место soname change, следует
именовать пакет с библиотекой в духе Debian policy (позаимствованной
оттуда позднее в mdk).
2. Наконец, если это столь важно, мантейнер может добавить строгую
сборочную зависимость.


-- 
ldv

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

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
> Что касается более сложной обработки, то тут надо вспомнить математику и
> хорошенько подумать.

Ну в общем да.  Нужно осилить топологию и теорию графов.  Потом нужно
переписать apt на ocaml'е. :)  Сейчас к апту очень серьезная претензия:
библиотека libapt-pkg не дает доступа к основным алгоритмам.  То есть
например алгоритм 'apt-get --print-uris install' закоден непосредственно
в apt-get.  Чтобы попробовать узнать, можно установить отдельно взятый
пакет или нет, приходится запускать apt-get и парсить его вывод.
Каждый такой запуск стоит порядка секунды, а большая часть времени
уходит на чтение/инициализацию кеша.  То есть нельзя достаточно быстро
проверить, какие пакеты в сизифе устанавливаемы, а какие нет.  Нельзя
загрузить кеш один раз и проверить все пакеты в пределах одного
процесса.

libapt-pkg дает доступ только ко внутренним структурам данных, но не
к алгоритмам.  Ни --print-uris, ни unmets из libapt-pkg извлечь нельзя.
Чем думали авторы апта?

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

Re: [devel] full list of unmets

[Anton Farygin]

Alexey Tourbin wrote:
> On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
>> Что касается более сложной обработки, то тут надо вспомнить математику и
>> хорошенько подумать.
> 
> Ну в общем да.  Нужно осилить топологию и теорию графов.  Потом нужно
> переписать apt на ocaml'е. :)  Сейчас к апту очень серьезная претензия:
> библиотека libapt-pkg не дает доступа к основным алгоритмам.  То есть
> например алгоритм 'apt-get --print-uris install' закоден непосредственно
> в apt-get.  Чтобы попробовать узнать, можно установить отдельно взятый
> пакет или нет, приходится запускать apt-get и парсить его вывод.
> Каждый такой запуск стоит порядка секунды, а большая часть времени
> уходит на чтение/инициализацию кеша.  То есть нельзя достаточно быстро
> проверить, какие пакеты в сизифе устанавливаемы, а какие нет.  Нельзя
> загрузить кеш один раз и проверить все пакеты в пределах одного
> процесса.

Для этого есть apt-pipe, который вполне реально IMHO научить жить под 
обычным пользователем (создавать сокет в заданном каталоге).

сейчас это выглядит вот так (тормозит только первый запуск):

[root@rider ~]# time apt-pipe ls >/dev/null
0.00user 0.00system 0:02.81elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2major+615minor)pagefaults 0swaps

[root@rider ~]# time apt-pipe ls >/dev/null
0.00user 0.00system 0:00.03elapsed 43%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+567minor)pagefaults 0swaps

[root@rider ~]# time apt-pipe showpkg icewm >/dev/null
0.00user 0.00system 0:00.01elapsed 80%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+568minor)pagefaults 0swaps


> 
> libapt-pkg дает доступ только ко внутренним структурам данных, но не
> к алгоритмам.  Ни --print-uris, ни unmets из libapt-pkg извлечь нельзя.
> Чем думали авторы апта?

авторов apt'а было слишком много, что бы они могли чем-то думать ;)

Rgds,
Rider

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Tue, Jun 20, 2006 at 11:38:35AM +0400, Anton Farygin wrote:
> Alexey Tourbin wrote:
> > On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
> >> Что касается более сложной обработки, то тут надо вспомнить математику и
> >> хорошенько подумать.
> > 
> > Ну в общем да.  Нужно осилить топологию и теорию графов.  Потом нужно
> > переписать apt на ocaml'е. :)  Сейчас к апту очень серьезная претензия:
> > библиотека libapt-pkg не дает доступа к основным алгоритмам.  То есть
> > например алгоритм 'apt-get --print-uris install' закоден непосредственно
> > в apt-get.  Чтобы попробовать узнать, можно установить отдельно взятый
> > пакет или нет, приходится запускать apt-get и парсить его вывод.
> > Каждый такой запуск стоит порядка секунды, а большая часть времени
> > уходит на чтение/инициализацию кеша.  То есть нельзя достаточно быстро
> > проверить, какие пакеты в сизифе устанавливаемы, а какие нет.  Нельзя
> > загрузить кеш один раз и проверить все пакеты в пределах одного
> > процесса.
> 
> Для этого есть apt-pipe, который вполне реально IMHO научить жить под 
> обычным пользователем (создавать сокет в заданном каталоге).

Я когда смотрел apt-pipe, он не умел жить под отдельным пользователем,
то есть всегда создавал сокет под /var/lib/apt.  Спасибо, посмотрю ещё.

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

Re: [devel] full list of unmets

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at@altlinux.ru> writes:
[skipped]
 >> Для этого есть apt-pipe, который вполне реально IMHO научить жить под 
 >> обычным пользователем (создавать сокет в заданном каталоге).

 > Я когда смотрел apt-pipe, он не умел жить под отдельным пользователем,
 > то есть всегда создавал сокет под /var/lib/apt.  Спасибо, посмотрю ещё.

Не умеет и сейчас. Желающие приделать ключик -- да не убоятся.

-- 

Re: [devel] full list of unmets

[Anton Farygin]

Alexey Tourbin wrote:
> On Tue, Jun 20, 2006 at 11:38:35AM +0400, Anton Farygin wrote:
>> Alexey Tourbin wrote:
>>> On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
>>>> Что касается более сложной обработки, то тут надо вспомнить математику и
>>>> хорошенько подумать.
>>> Ну в общем да.  Нужно осилить топологию и теорию графов.  Потом нужно
>>> переписать apt на ocaml'е. :)  Сейчас к апту очень серьезная претензия:
>>> библиотека libapt-pkg не дает доступа к основным алгоритмам.  То есть
>>> например алгоритм 'apt-get --print-uris install' закоден непосредственно
>>> в apt-get.  Чтобы попробовать узнать, можно установить отдельно взятый
>>> пакет или нет, приходится запускать apt-get и парсить его вывод.
>>> Каждый такой запуск стоит порядка секунды, а большая часть времени
>>> уходит на чтение/инициализацию кеша.  То есть нельзя достаточно быстро
>>> проверить, какие пакеты в сизифе устанавливаемы, а какие нет.  Нельзя
>>> загрузить кеш один раз и проверить все пакеты в пределах одного
>>> процесса.
>> Для этого есть apt-pipe, который вполне реально IMHO научить жить под 
>> обычным пользователем (создавать сокет в заданном каталоге).
> 
> Я когда смотрел apt-pipe, он не умел жить под отдельным пользователем,
> то есть всегда создавал сокет под /var/lib/apt.  Спасибо, посмотрю ещё.

Он и сейчас не умеет, но IMHO научить достаточно просто.

Rgds,
Rider

Re: [devel] full list of unmets

[Led]

В сообщении от 20 июня 2006 05:02 Alexey Tourbin написал(a):
> On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
> > Что касается более сложной обработки, то тут надо вспомнить математику и
> > хорошенько подумать.
>
> Ну в общем да.  Нужно осилить топологию и теорию графов.  Потом нужно
> переписать apt на ocaml'е. :)  Сейчас к апту очень серьезная претензия:
> библиотека libapt-pkg не дает доступа к основным алгоритмам.  То есть
> например алгоритм 'apt-get --print-uris install' закоден непосредственно
> в apt-get.  Чтобы попробовать узнать, можно установить отдельно взятый
> пакет или нет, приходится запускать apt-get и парсить его вывод.
> Каждый такой запуск стоит порядка секунды, а большая часть времени
> уходит на чтение/инициализацию кеша.  То есть нельзя достаточно быстро
> проверить, какие пакеты в сизифе устанавливаемы, а какие нет.  Нельзя
> загрузить кеш один раз и проверить все пакеты в пределах одного
> процесса.

А разве apt-shell не так делает?

-- 
Led.

Re: [devel] full list of unmets

[Anton Farygin]

Led wrote:
> В сообщении от 20 июня 2006 05:02 Alexey Tourbin написал(a):
>> On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
>>> Что касается более сложной обработки, то тут надо вспомнить математику и
>>> хорошенько подумать.
>> Ну в общем да.  Нужно осилить топологию и теорию графов.  Потом нужно
>> переписать apt на ocaml'е. :)  Сейчас к апту очень серьезная претензия:
>> библиотека libapt-pkg не дает доступа к основным алгоритмам.  То есть
>> например алгоритм 'apt-get --print-uris install' закоден непосредственно
>> в apt-get.  Чтобы попробовать узнать, можно установить отдельно взятый
>> пакет или нет, приходится запускать apt-get и парсить его вывод.
>> Каждый такой запуск стоит порядка секунды, а большая часть времени
>> уходит на чтение/инициализацию кеша.  То есть нельзя достаточно быстро
>> проверить, какие пакеты в сизифе устанавливаемы, а какие нет.  Нельзя
>> загрузить кеш один раз и проверить все пакеты в пределах одного
>> процесса.
> 
> А разве apt-shell не так делает?
> 

apt-shell надо всё-таки перезапускать ;)

apt-pipe рулит ;)

Rgds,
Rider

Re: [devel] full list of unmets

[Led]

В сообщении от 20 июня 2006 12:06 Anton Farygin написал(a):
> Led wrote:
> > В сообщении от 20 июня 2006 05:02 Alexey Tourbin написал(a):
> >> On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
> >>> Что касается более сложной обработки, то тут надо вспомнить математику
> >>> и хорошенько подумать.
> >>
> >> Ну в общем да.  Нужно осилить топологию и теорию графов.  Потом нужно
> >> переписать apt на ocaml'е. :)  Сейчас к апту очень серьезная претензия:
> >> библиотека libapt-pkg не дает доступа к основным алгоритмам.  То есть
> >> например алгоритм 'apt-get --print-uris install' закоден непосредственно
> >> в apt-get.  Чтобы попробовать узнать, можно установить отдельно взятый
> >> пакет или нет, приходится запускать apt-get и парсить его вывод.
> >> Каждый такой запуск стоит порядка секунды, а большая часть времени
> >> уходит на чтение/инициализацию кеша.  То есть нельзя достаточно быстро
> >> проверить, какие пакеты в сизифе устанавливаемы, а какие нет.  Нельзя
> >> загрузить кеш один раз и проверить все пакеты в пределах одного
> >> процесса.
> >
> > А разве apt-shell не так делает?
>
> apt-shell надо всё-таки перезапускать ;)

А expect для чего?

> apt-pipe рулит ;)

Не спорю. Просто его как раз ещё не пробовал:)

-- 
Led.

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Tue, Jun 20, 2006 at 11:46:16AM +0300, Led wrote:
> В сообщении от 20 июня 2006 05:02 Alexey Tourbin написал(a):
> > On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
> > > Что касается более сложной обработки, то тут надо вспомнить математику и
> > > хорошенько подумать.
> >
> > Ну в общем да.  Нужно осилить топологию и теорию графов.  Потом нужно
> > переписать apt на ocaml'е. :)  Сейчас к апту очень серьезная претензия:
> > библиотека libapt-pkg не дает доступа к основным алгоритмам.  То есть
> > например алгоритм 'apt-get --print-uris install' закоден непосредственно
> > в apt-get.  Чтобы попробовать узнать, можно установить отдельно взятый
> > пакет или нет, приходится запускать apt-get и парсить его вывод.
> > Каждый такой запуск стоит порядка секунды, а большая часть времени
> > уходит на чтение/инициализацию кеша.  То есть нельзя достаточно быстро
> > проверить, какие пакеты в сизифе устанавливаемы, а какие нет.  Нельзя
> > загрузить кеш один раз и проверить все пакеты в пределах одного
> > процесса.
> 
> А разве apt-shell не так делает?

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

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

Re: [devel] full list of unmets

[Led]

В сообщении от 20 июня 2006 18:35 Alexey Tourbin написал(a):
> On Tue, Jun 20, 2006 at 11:46:16AM +0300, Led wrote:
> > В сообщении от 20 июня 2006 05:02 Alexey Tourbin написал(a):
> > > On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
> > > > Что касается более сложной обработки, то тут надо вспомнить
> > > > математику и хорошенько подумать.
> > >
> > > Ну в общем да.  Нужно осилить топологию и теорию графов.  Потом нужно
> > > переписать apt на ocaml'е. :)  Сейчас к апту очень серьезная претензия:
> > > библиотека libapt-pkg не дает доступа к основным алгоритмам.  То есть
> > > например алгоритм 'apt-get --print-uris install' закоден
> > > непосредственно в apt-get.  Чтобы попробовать узнать, можно установить
> > > отдельно взятый пакет или нет, приходится запускать apt-get и парсить
> > > его вывод. Каждый такой запуск стоит порядка секунды, а большая часть
> > > времени уходит на чтение/инициализацию кеша.  То есть нельзя достаточно
> > > быстро проверить, какие пакеты в сизифе устанавливаемы, а какие нет. 
> > > Нельзя загрузить кеш один раз и проверить все пакеты в пределах одного
> > > процесса.
> >
> > А разве apt-shell не так делает?
>
> Это несколько облегчает, но не отменяют проблему.

Это была реплика на "Нельзя загрузить кеш один раз и проверить все пакеты в 
пределах одного процесса". Не более того...

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

ИМХО на перле "свет клином не сошёлся".

-- 
Led.

Re: [devel] full list of unmets

[Michael Shigorin]

On Tue, Jun 20, 2006 at 04:55:01AM +0400, Alexey Tourbin wrote:
> В общем случае это не так-то просто реализовать.

Поэтому и не надо сразу бросаться на общий случай.  Здравый смысл
подсказывает, что в процессе решения частных накапливается опыт и
обычно вылазят вещи, которые не были понятны заранее и по меньшей
мере оттянули бы хоть какое-то общее решение.

См. "the rise of worse is better" в качестве экстремума ;)

> Может быть можно выделать некоторые частные случаи и отдать их
> на откуп автоматике.

Не "может быть", а именно!

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] замкнутое подмножество (was: full list of unmets)

[Michael Shigorin]

On Tue, Jun 20, 2006 at 04:17:25AM +0400, Dmitry V. Levin wrote:
> Кстати, если с волшебными алгоритмами ничего не выйдет, может
> просто выделить небольшое подмножество Сизифа, которое будет
> гарантированно замкнутым (например, как Owl)?

main / contrib?  По критериям "замкнуто" (если и не "грозились
поддерживать").

Я -- за.  Feeble practice вида "держать в некоторых vserver'ах
Master/2.4 main", по крайней мере, оказалась не сильно хлопотной.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] full list of unmets

[Anton Farygin]

Dmitry V. Levin wrote:
> On Tue, Jun 20, 2006 at 04:04:10AM +0400, Alexey Tourbin wrote:
>> Я также сомневаюсь, что удастся найти "волшебный" алгоритм, который
>> блокирует анметы на входе.  Например, вчера в сизиф прошла новая версия
>> firefox.  Часть плагинов была пересобрана с новой версией firefox, тогда
>> как другая часть не была пересобрана.  Может быть эти пакеты просто
>> забыли автоматически пересобрать?  От incoming/incominger'а по этому
>> поводу ничего не слышно.
> 
> Я не знаю, существует ли этот "волшебный" алгоритм.
> Но у меня есть такое наблюдение: среди множества пакетов, приходящих в
> течение суток в /i/S, всегда есть такие, которые не порождают новых
> unmet'ов.  Я думаю, что выявлять такие пакеты теперь, когда Legion по моей
> просьбе написал оптимизированную замену genpkglist, можно быстро и дёшево.
> Я полагаю, что для начала нужно обеспечить быстрое (автоматическое, без
> участия человека вообще) прохождение этих пакетов из /i/S в Sisyphus.
> Я удивляюсь тому факту, что это ещё не реализовано.
> 
>> А на x86_64 анметов вообще 700 штук.  Будет у нас Фриз, Бранч или
>> Херанч, или не будет, в общем-то ясно, что от проблемы анметов никуда
>> не уйти.  По-моему до "ловли блох" ещё далеко (и пока нет веских
>> оснований думать, что к зиме будет ближе).
> 
> Должен отметить, что меня как пользователя Сизифа эти unmet'ы не волнуют,
> ибо они меня как пользователя Сизифа просто не затрагивают.
> 
> Иногда мне кажется, что я единственный пользователь Сизифа, и в такие
> моменты мне хочется просто удалить все пакеты с unmet'ами, а также все
> несобирающиеся пакеты, и ещё некоторое количество пакетов, которые мне
> просто не нравятся.  Хорошо, что это быстро проходит. :)
> 
> Кстати, если с волшебными алгоритмами ничего не выйдет, может просто
> выделить небольшое подмножество Сизифа, которое будет гарантированно
> замкнутым (например, как Owl)?

И назвать его Sisyphus core.

Отличная идея, без шуток.

Rgds,
Rider

Re: [devel] full list of unmets

[Kirill A. Shutemov]

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

On 11:34 Tue 20 Jun, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> > Кстати, если с волшебными алгоритмами ничего не выйдет, может просто
> > выделить небольшое подмножество Сизифа, которое будет гарантированно
> > замкнутым (например, как Owl)?
> 
> И назвать его Sisyphus core.
> 
> Отличная идея, без шуток.

+1

-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

По "техническим причинам" я буду молчать или реагировать с бооольшой
задержкой на все почтовое в лучшем случае до понедельника следующей недели.
		-- ldv in devel@

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

Re: [devel] full list of unmets

[Денис Смирнов]

On Tue, Jun 20, 2006 at 04:17:25AM +0400, Dmitry V. Levin wrote:

DVL> Кстати, если с волшебными алгоритмами ничего не выйдет, может просто
DVL> выделить небольшое подмножество Сизифа, которое будет гарантированно
DVL> замкнутым (например, как Owl)?

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Какой-то патч страшненький у тебя получился.
		-- ldv in #6099

Re: [devel] full list of unmets

[Dmitry V. Levin]

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

On Tue, Jun 20, 2006 at 07:46:01PM +0400, Денис Смирнов wrote:
> On Tue, Jun 20, 2006 at 04:17:25AM +0400, Dmitry V. Levin wrote:
> 
> DVL> Кстати, если с волшебными алгоритмами ничего не выйдет, может просто
> DVL> выделить небольшое подмножество Сизифа, которое будет гарантированно
> DVL> замкнутым (например, как Owl)?
> 
> Я об этом уже месяц кричу на каждом углу. Только я предлагаю выделять не
> руками, а роботом.

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

Таких пакетов не может быть много.


-- 
ldv

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

Re: [devel] full list of unmets

[Денис Смирнов]

On Sun, Jun 25, 2006 at 03:23:41PM +0400, Dmitry V. Levin wrote:
>> Я об этом уже месяц кричу на каждом углу. Только я предлагаю выделять не
>> руками, а роботом.
DVL> Роботом можно только помогать. 

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

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

Да, согласен. Но при этом очень хочется иметь репозиторий, в котором все
пакеты и всегда в полной готовности. Или максимально близкой к полной, но
пакеты таки все.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Если программа полностью отлажена, ее нужно будет скорректировать.

Re: [devel] full list of unmets

[Michael Shigorin]

On Tue, Jun 20, 2006 at 04:04:10AM +0400, Alexey Tourbin wrote:
> В любом случае, любой сколько-нибудь "волшебный" алгоритм должен был бы
> зарубить новый firefox, потому что он увеличивает количество анметов.

Алгоритм оказался бы дураком, поскольку нифига не читает даже
bugtraq@ и не в состоянии осознать, что свежий firefox всегда
важнее примочек.

> 2) почему плагины так жестко зависят от версии firefox, так что
> их даже приходится пересобирать при sub-micro изменении версии,
> очевидно багфиксной?  Кто и зачем придумал такие жесткие
> зависимости?

Насколько помню, это суровая правда жизни (как-то задавался этим
же вопросом ради mozilla-uk).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] full list of unmets

[Денис Смирнов]

On Tue, Jun 20, 2006 at 10:23:53AM +0300, Michael Shigorin wrote:

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

apt-get upgrade оказался бы точно таким же дураком.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Зачем вам понадобился -L/usr/lib?
		-- ldv in sisyphus@

Re: [devel] full list of unmets

[Alexey Gladkov]

Alexey Tourbin пишет:
> Короче, у меня два вопроса по поводу вчерашнего firefox:
> 
> 1) почему робот автоматически не пересобрал все остальные плагины?
> в результате количество анметов увеличилось более чем на 20.

Сколько можно повторять: _нету_у_нас_этого_робота_ ?!
Когда он будет всем сразу об этом скажут.

Часть плагинов пересобрал я сам ... остальные не заметил так как ими
не пользуюсь. Я пересоберу их не глядя ... хотя это не хочется делать
так как я не могу гарантировать их работоспособность с новой версией
firefox.

> 2) почему плагины так жестко зависят от версии firefox, так что их даже
> приходится пересобирать при sub-micro изменении версии, очевидно
> багфиксной?  Кто и зачем придумал такие жесткие зависимости?

В начале это было необходимо ... сейчас можно не ставить зависимость
на версию... те кому это нужно могут поставить менее жёсткую зависимость.

-- 
Rgrds, legion

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Tue, Jun 20, 2006 at 01:07:27PM +0400, Alexey Gladkov wrote:
> > 2) почему плагины так жестко зависят от версии firefox, так что их даже
> > приходится пересобирать при sub-micro изменении версии, очевидно
> > багфиксной?  Кто и зачем придумал такие жесткие зависимости?
> 
> В начале это было необходимо ... сейчас можно не ставить зависимость
> на версию... те кому это нужно могут поставить менее жёсткую зависимость.

Нужно поставить менее жесткую зависимость.  Если цифры в версиях вообще
что-либо означают, то $major.$minor.$micro.$sub_micro нужно понимать так:

1) $micro фиксирует совместимость на уровне интерфейсов;
2) $sub_micro содержит исключительно багфиксы.

Тогда совместимость нужно зафиксировать на уровне $major.$minor, в
данном случае плагины должны зависеть от чего-то вроде firefox_api = 1.5.
Поскольку есть отдельный пакет rpm-build-firefox, этот вопрос можно
решить один раз и надолго для всех плагинов.

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