[devel] RFC: test-libs

[devel] RFC: test-libs

[Alexey Tourbin]

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

Здравствуйте.

Суть вопроса в следующем: разделяемые библиотеки (по крайней мере те из
них, которые находятся в публичных местах) не должны содержать undefined
symbols.  Такие библиотеки как бы "замкнуты".  Это дает возможность
"свободно" с ними линковаться.  В этом одно из преимуществ разделяемых
библиотек: для правильной линковки с ними, по идее, не требуется никакой
внешней мета-информации (навроде *.la файлов).

Пример "не замкнутой" библиотеки:

$ ls -l /usr/lib/libxlog.so
lrwxrwxrwx  1 root root 22 Jun 16 02:05 /usr/lib/libxlog.so -> ../../lib/libxlog.so.0
$ ldd -r /usr/lib/libxlog.so
        libc.so.6 => /lib/i686/libc.so.6 (0x4001f000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
undefined symbol: uuid_unparse  (/usr/lib/libxlog.so)
undefined symbol: libxfs_readbufr       (/usr/lib/libxlog.so)
undefined symbol: xlog_recover_do_trans (/usr/lib/libxlog.so)
undefined symbol: libxfs_putbuf (/usr/lib/libxlog.so)
undefined symbol: uuid_is_null  (/usr/lib/libxlog.so)
undefined symbol: uuid_compare  (/usr/lib/libxlog.so)
undefined symbol: libxfs_getbuf (/usr/lib/libxlog.so)
$

Доказательство того, что с этой библиотекой нельзя "просто так"
слинковаться:

$ cat ~/ldtest.c
main(){}
$ gcc ~/ldtest.c -lxlog
/usr/lib/gcc/i586-alt-linux/3.4.3/../../../libxlog.so: undefined reference to `uuid_unparse'
/usr/lib/gcc/i586-alt-linux/3.4.3/../../../libxlog.so: undefined reference to `libxfs_readbufr'
/usr/lib/gcc/i586-alt-linux/3.4.3/../../../libxlog.so: undefined reference to `xlog_recover_do_trans'
/usr/lib/gcc/i586-alt-linux/3.4.3/../../../libxlog.so: undefined reference to `libxfs_putbuf'
/usr/lib/gcc/i586-alt-linux/3.4.3/../../../libxlog.so: undefined reference to `uuid_is_null'
/usr/lib/gcc/i586-alt-linux/3.4.3/../../../libxlog.so: undefined reference to `uuid_compare'
/usr/lib/gcc/i586-alt-linux/3.4.3/../../../libxlog.so: undefined reference to `libxfs_getbuf'
collect2: ld returned 1 exit status
$

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

Список пакетов для формирования такой сборочной среды формируется
примерно так:

: This is how the above list was formed:
cd Sisyphus/files/i586/RPMS
for f in *.rpm ; do if rpm -qpl $f |grep -E '^(/usr(/X11R6)?)?/lib/lib[^/]+\.so';
then rpm -qp --qf '%{NAME}\n' $f; fi; done
: NOTE: all -devel packages removed.

В чрут встаёт около 1000 пакетов -- это примерно 1/5 часть сизифа.
Далее выполняется следующий скрипт:

%build
set +x
for lib in {,/usr,/usr/X11R6}/lib*/lib*.so*; do
	type="$(file -bL "$lib")" ||: maybe broken symlink
	[ -z "${type##*ELF*}" -a -z "${type##*shared*}" ] ||
		{ echo "$lib: $type" >&2; continue; }
	ldd -r "$lib" >/dev/null 2>stderr
	[ -s stderr ] || continue
	pkg="$(rpm -qf --qf '%{NAME}' "$lib")" || pkg=UNKNOWN
	echo "$lib $pkg"
	cat stderr |sed -e "s/^/$pkg /" >&2
done

По результатам выполнения скрипта обнаружено примерно 300 "не замкнутых"
библиотек (217 пакетов).  Ниже перечислены все эти библиотеки (но только
по одному undefined символу из каждой библиотеки, т.к. полный список
очень большой).

libconsole-tools	/lib/libcfont.so.0	unimapdesc_addpair
libconsole-tools	/lib/libconsole.so.0	utf8_to_ucs2
samba-common	/lib/libnss_wins.so	yperr_string
glibc-core	/lib/libthread_db-1.0.so	ps_pglobal_lookup
libxfs	/lib/libxlog.so.0	uuid_unparse
liba2ps	/usr/lib/liba2ps.so.1	program_name
graphviz	/usr/lib/libagraph.so.0	Dttree
kdepim-akregator	/usr/lib/libakregatorprivate.so	static_QUType_int
liballegro	/usr/lib/liballeg-4.1.14.so	_xwin_write_line_asm
amanda-client	/usr/lib/libamclient-2.4.5.so	debug
amanda	/usr/lib/libamserver-2.4.5.so	debug
amanda-common	/usr/lib/libamtape-2.4.5.so	sanitise_filename
libareafix	/usr/lib/libareafix.so.1.9	srealloc
kdemultimedia-arts	/usr/lib/libartsmidi_idl.so	_ZN4Arts16SynthModule_base4_IIDE
kdemultimedia-arts	/usr/lib/libarts_mpeglib-0.3.0.so.0	_ZTVN4Arts21StreamPlayObject_skelE
kdemultimedia-arts	/usr/lib/libarts_xine.so	_x_ao_new_port
kdegames-atlantik	/usr/lib/libatlantikclient.so	_ZN15KExtendedSocket10enableReadEb
kdegames-atlantik	/usr/lib/libatlantikui.so	_ZTV7KPixmap
libautotrace	/usr/lib/libautotrace.so.3	GetMagickInfo
libavc1394	/usr/lib/libavc1394.so.0	raw1394_stop_fcp_listen
libavifile	/usr/lib/libaviplayavcodec-0.7.so.0	deflate
libavifile	/usr/lib/libaviplayavformat-0.7.so.0	mjpeg_encoder
libbfd	/usr/lib/libbfd-2.15.94.0.2.2.so	_sch_istable
libbigloo	/usr/lib/libbigloofth_s-2.6f.so	make_pair
libbigloo	/usr/lib/libbigloogc-2.6f.so	get_top_of_stack
libbigloo	/usr/lib/libbigloogc_fth-2.6f.so	pthread_create
libbigloo	/usr/lib/libbigloo_s-2.6f.so	make_pair
libbonobo	/usr/lib/libbonobo-print.so.2	CORBA_exception_free
libbonobo	/usr/lib/libbonobo.so.2	ORBit_TypeCode_epv
libbonobo	/usr/lib/libbonobox.so.2	TC_string_struct
boost-test	/usr/lib/libboost_prg_exec_monitor-gcc-1_32.so.1.32.0	_Z8cpp_mainiPPc
boost-python	/usr/lib/libboost_python-gcc-1_32.so.1.32.0	PyModule_Type
boost-test	/usr/lib/libboost_test_exec_monitor-gcc-1_32.so.1.32.0	_Z9test_mainiPPc
boost-test	/usr/lib/libboost_unit_test_framework-gcc-1_32.so.1.32.0	_Z20init_unit_test_suiteiPPc
libcapplet	/usr/lib/libcapplet.so.1	gtk_marshal_NONE__NONE
libcommoncpp2	/usr/lib/libccext2-1.2.so.1	_ZN3ost9ExceptionD1Ev
libcommoncpp2	/usr/lib/libccgnu2-1.2.so.1	pthread_yield
libcdparanoia	/usr/lib/libcdda_paranoia.so.0	cdda_sector_gettrack
libcdf	/usr/lib/libcdf_idl.so.0	IDL_StoreScalar
libcdk	/usr/lib/libcdk.so.4	acs_map
libfox	/usr/lib/libCHART-1.2.so.0	_ZN2FX8FXWindow9imageTypeE
libcinepaint	/usr/lib/libcinepaint.so.0	gtk_marshal_NONE__NONE
graphviz	/usr/lib/libcircogen.so.0	E_weight
clanlib	/usr/lib/libclanDisplay.so.0.6.3	_ZN18CL_ClanApplication3appE
clanlib-gl	/usr/lib/libclanGL.so.0.6.3	_ZN18CL_ClanApplication3appE
clanlib-gui	/usr/lib/libclanGUI.so.0.6.3	_ZN10CL_Display20pop_translate_offsetEv
clanlib-jpeg	/usr/lib/libclanJPEG.so.0.6.3	_ZTV9CL_Target
clanlib-lua	/usr/lib/libclanLua.so.0.6.3	_ZTV9CL_Target
clanlib-mikmod	/usr/lib/libclanMikMod.so.0.6.3	_ZN14CL_SoundBuffer6createEP22CL_StreamSoundProviderb
clanlib-png	/usr/lib/libclanPNG.so.0.6.3	_ZTV9CL_Target
clanlib-ttf	/usr/lib/libclanTTF.so.0.6.3	_ZTV9CL_Target
libobexftp	/usr/lib/libcobexbfb.so.0	OBEX_CustomDataFeed
libcolorifer	/usr/lib/libcolorifer.so.0	pcreposix_regfree
graphviz	/usr/lib/libcommon.so.0	agnodeattr
libomniORB	/usr/lib/libCOS4.so.0	_ZN5CORBA8TypeCode15marshalTypeCodeEPS0_R9cdrStream
libomniORB	/usr/lib/libCOSDynamic4.so.0	_ZN12CosLifeCycle10NotMovable16insertToAnyFnNCPE
cppunit	/usr/lib/libcppunit-1.10.so.2	dlclose
libcroco	/usr/lib/libcroco-0.6.so.3	xmlFree
libcups	/usr/lib/libcupsimage.so.2	cupsTempFd
kdesdk-cervisia	/usr/lib/libcvsservice.so	_ZN7QString11shared_nullE
cooledit	/usr/lib/libCw.so	XSetInputFocus
libdbh	/usr/lib/libdbh-1.0.so.1	pow
libdbus-gcj	/usr/lib/libdbus-gcj-1.so	_ZN4java4lang29UnsupportedOperationException6class$E
libdc1394	/usr/lib/libdc1394_control.so.11	raw1394_set_iso_handler
kdevelop-common	/usr/lib/libdesignerintegration.so	static_QUType_QString
libdevhelp	/usr/lib/libdevhelp-1.so.0	geometry
libdict-cpp	/usr/lib/libdict++.so.0	__gxx_personality_v0
libdjvu	/usr/lib/libdjvulibre.so	pthread_create
kdevelop-common	/usr/lib/libdocchmplugin.so	_ZN5QChar4nullE
kdevelop-common	/usr/lib/libdocumentation_interfaces.so	static_QUType_ptr
graphviz	/usr/lib/libdotgen.so.0	MaxIter
libecasound	/usr/lib/libecasound.so.14	_Z12kvu_numtostri
evolution-data-server	/usr/lib/libedataserverui-1.2.so.4	gtk_widget_hide_on_delete
libefs	/usr/lib/libefs.so.1	g_direct_equal
fuse-encfs	/usr/lib/libencfs.so.1	EVP_CIPHER_CTX_init
Epplets	/usr/lib/libepplet.so	glXMakeCurrent
esound	/usr/lib/libesddsp.so.0	esd_get_all_info
libesmart	/usr/lib/libesmart_container.so.0	ecore_time_get
ethereal-base	/usr/lib/libethereal.so.0	adns_finish
graphviz	/usr/lib/libexpr.so.0	sfstdin
libfaac	/usr/lib/libfaac.so.0	log
graphviz	/usr/lib/libfdpgen.so.0	specificFlags
libfftw3	/usr/lib/libfftw3f_threads.so.3	fftwf_dft_solve
libfftw3	/usr/lib/libfftw3l_threads.so.3	fftwl_dft_solve
libfftw3	/usr/lib/libfftw3_threads.so.3	fftw_dft_solve
libfftw	/usr/lib/libfftw_threads.so.2	fftw_die
libfidoconf	/usr/lib/libfidoconfig.so.1.9	tree_srch
dirdiff	/usr/lib/libfilecmp.so.0.0	Tcl_Alloc
libflac++	/usr/lib/libFLAC++.so.5	__cxa_pure_virtual
libflash	/usr/lib/libflash-0.4.so.10	_Znaj
flite	/usr/lib/libflite_cmulex.so.1	val_car
flite	/usr/lib/libflite_cmu_time_awb.so.1	clunits_synth
flite	/usr/lib/libflite_cmu_us_kal16.so.1	cmu_lex
flite	/usr/lib/libflite.so.1	sqrt
flite	/usr/lib/libflite_usenglish.so.1	val_string_1
libfltk	/usr/lib/libfltk_forms.so.1.1	_ZTVN10__cxxabiv120__si_class_type_infoE
libfpx	/usr/lib/libfpx.so.1	_ZTVN10__cxxabiv117__class_type_infoE
libfreewrl	/usr/lib/libFreeWRLFunc.so	dpy
libfvh	/usr/lib/libfvh.so.2	log
libfwbuilder	/usr/lib/libfwcompiler.so.6	_ZTIN12libfwbuilder8FWObjectE
libfxscintilla	/usr/lib/libfxscintillanolexer.so	_ZN2FX8FXWindow15urilistTypeNameE
libgal2	/usr/lib/libgal-a11y-2.4.so.0	e_repos_delete_shift
libgal	/usr/lib/libgal.so.21	xmlSaveNoEmptyTags
libgammu	/usr/lib/libGammu.so.0	sin
libgc	/usr/lib/libgccpp.so.1	__gxx_personality_v0
libGConf	/usr/lib/libgconf-gtk-1.so.1	gconf_engine_dir_exists
libgda	/usr/lib/libgda-clientcpp.so.0	_ZNSs4_Rep20_S_empty_rep_storageE
libgda	/usr/lib/libgda-client.so.0	gtk_marshal_NONE__NONE
libgda	/usr/lib/libgda-server.so.0	POA_GDA_Connection__init
libgtkmm2	/usr/lib/libgdkmm-2.4.so.1	_ZNK5Pango10LayoutLine4gobjEv
fontforge	/usr/lib/libgdraw.so	unicode_alternates
libgeda	/usr/lib/libgeda.so.22	quit_func
libGeoIP	/usr/lib/libGeoIPUpdate.so.0	GeoIPDBFileName
libglade-gnomedb	/usr/lib/libglade-gnomedb.so.0	glade_gnome_init
libglade-gnome	/usr/lib/libglade-gnome.so.0	glade_standard_build_children
libgoblin	/usr/lib/libglpk2.7.so	NoRestr
libgmime	/usr/lib/libgmime-2.0.so.2	g_thread_use_default_impl
libgnucash	/usr/lib/libgnc-app-file-gnome.so	gnc_should_log
gdk-pixbuf-gnomecanvas	/usr/lib/libgnomecanvaspixbuf.so.1	gdk_pixbuf_unref
libgnome-mag	/usr/lib/libgnome-mag.so.2	ORBit_TypeCode_epv
gnome-libs	/usr/lib/libgnome.so.32	poptHelpOptions
gnome-libs	/usr/lib/libgnomeui.so.32	gnome_user_dir
gnome-libs	/usr/lib/libgnorbagtk.so.0	TC_string_struct
gnome-libs	/usr/lib/libgnorba.so.27	gdk_root_window
libgcj3.4	/usr/lib/lib-gnu-java-awt-peer-gtk.so.5	_ZN4java2io17InputStreamReader6class$E
libgpsim	/usr/lib/libgpsimcli.so.0	bp
libgpsim	/usr/lib/libgpsim_modules.so.0	trace
libgpsim	/usr/lib/libgpsim.so.0	use_gui
libgsl	/usr/lib/libgsl.so.0	cblas_dsdot
gsmlib	/usr/lib/libgsmext.so.1	_ZNSs4_Rep20_S_empty_rep_storageE
gsmlib	/usr/lib/libgsmme.so.1	_ZTTSt14basic_ifstreamIcSt11char_traitsIcEE
gst-editor	/usr/lib/libgstdebugui.so.0	gste_get_ui_file
libstroke	/usr/lib/libgstroke.so.0	g_str_hash
autogen	/usr/lib/libguileopts.so.0	gh_eval_str
fontforge	/usr/lib/libgunicode.so	local_encoding
libgwenhywfar	/usr/lib/libgwenui.so.1	GWEN_XMLNode_free
libmpeg4ip	/usr/lib/libh264util.so.0	Base64ToBinary
libnessus	/usr/lib/libhosts_gatherer.so.2	__dn_expand
libhowl	/usr/lib/libhowl.so.0	pthread_mutexattr_settype
libhptzip	/usr/lib/libhptzip.so.0	crc32
id3lib	/usr/lib/libid3-3.8.so.3	_ZTTSt14basic_ifstreamIcSt11char_traitsIcEE
libORBit	/usr/lib/libIIOP.so.0	g_slist_free_1
mono	/usr/lib/libikvm-native.so	g_module_close
openexr	/usr/lib/libIlmImf.so.2	_ZN3Iex7BaseExcD1Ev
openexr	/usr/lib/libImath.so.2	_ZTIN3Iex7BaseExcE
iquicklauncher	/usr/lib/libiquicklauncherapplet.so	_ZN17KActionCollectionC1EP7QWidgetPKcP9KInstance
kdepim-kaddressbook	/usr/lib/libkaddressbook.so	_ZN13KCMultiDialogD1Ev
kawa	/usr/lib/libkawa.so	_ZN4java4lang30ArrayIndexOutOfBoundsException6class$E
koffice-kchart	/usr/lib/libkdchart.so	static_QUType_bool
kdeedu-libs	/usr/lib/libkdeeducore.so	_ZN7QString11shared_nullE
kdebase-libs	/usr/lib/libkdeinit_kcminit.so	_ZN5QChar4nullE
kdevelop-common	/usr/lib/libkdevbuildbase.so	_ZN7QString11shared_nullE
kdevelop-common	/usr/lib/libkdevbuildtoolswidgets.so	static_QUType_QString
kdevelop-common	/usr/lib/libkdevcppparser.so	_ZN5QChar4nullE
kdevelop-common	/usr/lib/libkdevextras.so	_ZN6QGList5clearEv
kdevelop-common	/usr/lib/libkdevkdelibsimporter.so	_ZNK11KLibFactory9classNameEv
kdevelop-common	/usr/lib/libkdevwidgets.so	static_QUType_QString
kftpgrabber	/usr/lib/libkftpinterfaces.so	static_QUType_int
kdepim-libs	/usr/lib/libkholidays.so	_ZN7QString11shared_nullE
kdevelop-common	/usr/lib/libkinterfacedesigner.so	static_QUType_ptr
kdepim-kmobile	/usr/lib/libkmobiledevice.so	static_QUType_ptr
kdepim-korganizer	/usr/lib/libkocorehelper.so	_ZN7QString11shared_nullE
kdewebdev-kommander	/usr/lib/libkommanderplugin.so	_ZN7QString11shared_nullE
kdewebdev-kommander	/usr/lib/libkommanderwidget.so	static_QUType_ptr
kdewebdev-kommander	/usr/lib/libkommanderwidgets.so	_ZN16KommanderFactory11loadPluginsEb
kdebase-konqueror	/usr/lib/libkonqsidebarplugin.so	static_QUType_ptr
kdelibs	/usr/lib/libkscreensaver.so	kss_applicationName
kdebase-wm	/usr/lib/libksplashthemes.so	static_QUType_int
ktechlab	/usr/lib/libktechlab_gpsim.so	_ZTI9Processor
labplot	/usr/lib/libLabPlotcephes.so.1	log
labplot	/usr/lib/libLabPlotqwtplot3d.so.0	static_QUType_double
kdevelop-common	/usr/lib/liblang_debugger.so	static_QUType_QString
libmjpegtools	/usr/lib/liblavfile-1.7.so.0	mjpeg_error_exit1
libmjpegtools	/usr/lib/liblavplay-1.7.so.0	mjpeg_warn
libmjpegtools	/usr/lib/liblavrec-1.7.so.0	lav_fileno
mozilla	/usr/lib/libldap50.so	pthread_getspecific
libldap	/usr/lib/libldap_r-2.2.so.7	pthread_create
liblineak	/usr/lib/liblineak.so.0	dlerror
libat-spi	/usr/lib/libloginhelper.so.0	_ORBIT_skel_small_Bonobo_Unknown_queryInterface
liblua4	/usr/lib/liblualib.so.4	lua_setcallhook
liblua5	/usr/lib/liblualib.so.5	lua_resume
captive-lufs	/usr/lib/liblufs-captivefs-1.1.5.so	lu_opt_getchar
lufs-plugins	/usr/lib/liblufs-ftpfs.so	lu_cache_add_dir
lufs-plugins	/usr/lib/liblufs-gnetfs.so	lu_atomic_read
lufs	/usr/lib/liblufs-localfs.so	lu_cache_add2dir
lufs-plugins	/usr/lib/liblufs-locasefs.so	lu_opt_getchar
lufs-plugins	/usr/lib/liblufs-sshfs.so	lu_atomic_read
librtai	/usr/lib/liblxrt.so.1	pthread_yield
magma	/usr/lib/libmagmamsg.so	clist_get_flags
magma	/usr/lib/libmagma_nt.so	dlclose
magma	/usr/lib/libmagma.so	pthread_rwlock_rdlock
libmas	/usr/lib/libmasc.so	clock_gettime
libhowl	/usr/lib/libmDNSResponder.so.0	sw_socket_recvfrom
clanlib-mikmod	/usr/lib/libmikmod.so.2	dlclose
libmikmod	/usr/lib/libmikmod.so.2.0.4	dlclose
sendmail-libs	/usr/lib/libmilter.so	pthread_create
gnome-mlview	/usr/lib/libmlview.so	g_cclosure_marshal_VOID__POINTER
libmnogosearch	/usr/lib/libmnogosearch-3.2.so	UdmUniStrCmp
libmodplug	/usr/lib/libmodplug.so.0	_Znaj
liblame	/usr/lib/libmp3lame.so.0	log
libmpeg4ip	/usr/lib/libmp4av.so.0	MP4GetSampleSize
libmpeg4ip	/usr/lib/libmp4util.so.0	_ZN10CBitstream4initEPKhj
libmpeg4ip	/usr/lib/libmpeg4ipSDL-1.2.so.0	SDL_CreateThread
mpfc	/usr/lib/libmpfc-1.3.5.so	dlerror
mpfc	/usr/lib/libmpfcwnd-1.3.5.so	cfg_new_list
kdemultimedia-arts	/usr/lib/libmpg123.so	prgName
libmpeg4ip	/usr/lib/libmsg_queue.so.0	SDL_DestroyMutex
ORBit2	/usr/lib/libname-server-2.so	CosNaming_NamingContext__classid
libORBit2ORBit2	/usr/lib/libname-server-2.so.0	CosNaming_NamingContext__classid
libncursesxx	/usr/lib/libncursesxx.so.0.0.1beta4	COLOR_PAIRS
graphviz	/usr/lib/libneatogen.so.0	MaxIter
libnessus	/usr/lib/libnessus.so.2	pcap_close
libnetcdf	/usr/lib/libnetcdf_c++.so.0	_ZNSs4_Rep11_S_terminalE
libnetpbm	/usr/lib/libnetpbm.so.10	log
libnet-snmp	/usr/lib/libnetsnmpagent.so.5	version_sysoid
libnet-snmp	/usr/lib/libnetsnmphelpers.so.5	netsnmp_ncompare_netsnmp_index
libnet-snmp	/usr/lib/libnetsnmpmibs.so.5	usmHMACSHA1AuthProtocol
libnet-snmp	/usr/lib/libnetsnmp.so.5	EVP_DigestInit
libnet-snmp	/usr/lib/libnetsnmptrapd.so.5	netsnmpUDPDomain
libobexftp	/usr/lib/libobexftp.so.0	OBEX_CharToUnicode
libopenbox	/usr/lib/libobparser.so.1	g_slist_prepend
libopenbox	/usr/lib/libobrender.so.1	g_int_hash
libunixODBC	/usr/lib/libodbccr.so.1	dm_log_write
liboggflac++	/usr/lib/libOggFLAC++.so.2	__cxa_pure_virtual
openjade	/usr/lib/libogrove.so.0	__cxa_pure_virtual
libbfd	/usr/lib/libopcodes-2.15.94.0.2.2.so	bfd_get_arch
libORBit	/usr/lib/libORBitCosNaming.so.0	TC_string_struct
libORBit	/usr/lib/libORBit.so.0	IIOPIncomingMessageHandler
libgcj3.3	/usr/lib/lib-org-w3c-dom.so.0	_ZTVN4java4lang5ClassE
libgcj3.3	/usr/lib/lib-org-xml-sax.so.0	_ZN4java4lang30ArrayIndexOutOfBoundsException6class$E
openjade	/usr/lib/libospgrove.so.0	_ZN14OpenJade_Grove8ClassDef7elementE
openjade	/usr/lib/libostyle.so.0	_ZTVN6OpenSP17InputSourceOriginE
libots	/usr/lib/libots-1.so.0	g_utf8_skip
graphviz	/usr/lib/libpack.so.0	Verbose
libparted	/usr/lib/libparted-1.6.so.12	dlerror
php-libs	/usr/lib/libphp-4.3.12.so	php_startup_internal_extensions
w3c-libwww	/usr/lib/libpics.so.0	WWW_TraceFlag
libpilot-link	/usr/lib/libpisock++.so.0	_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
libpilot-link	/usr/lib/libpisync.so.0	dlp_ReadNextModifiedRec
plasticfs	/usr/lib/libplasticfs.so	__libc_xstat64
plib	/usr/lib/libplibfnt.so.0	_Z10ulSetError10ulSeverityPKcz
plib	/usr/lib/libplibpuaux.so.0	_ZTV11puInputBase
plib	/usr/lib/libplibpu.so.0	_ZN14ulRTTITypeinfoD1Ev
plib	/usr/lib/libplibsg.so.0	_Z10ulSetError10ulSeverityPKcz
plib	/usr/lib/libplibssgaux.so.0	_ssgTexCoord00
plib	/usr/lib/libplibssg.so.0	_ZN9sgFrustum6updateEv
libpoppler	/usr/lib/libpoppler-qt.so.0	_ZN7QString11shared_nullE
libprelude	/usr/lib/libprelude.so.0	lt_dlforeachfile
mozilla	/usr/lib/libprldap50.so	PR_SetThreadPrivate
kdevelop-common	/usr/lib/libprofileengine.so	_ZN7QString11shared_nullE
kdevelop-common	/usr/lib/libprojectmanager_interfaces.so	static_QUType_ptr
libpstoedit	/usr/lib/libpstoedit.so.0	dlerror
quakeforge-libs	/usr/lib/libQFjs.so.1	viewdelta
quakeforge-libs-gl	/usr/lib/libQFmodels_gl.so.1	d_8to24table
quakeforge-libs-gl	/usr/lib/libQFrenderer_gl.so.1	qfglEnable
quakeforge-libs-sw	/usr/lib/libQFrenderer_sw32.so.1	frustum
libqt1-qimgio	/usr/lib/libqimgio.so	jpeg_resync_to_restart
libquicktime	/usr/lib/libquicktime1394.so.0	pthread_create
libqt2-Xt	/usr/lib/libqxt.so	widgetClassRec
libfftw	/usr/lib/librfftw.so.2	fftw_die
libavc1394	/usr/lib/librom1394.so.0	raw1394_write
librosegarden-alsa	/usr/lib/libRosegardenSequencer-alsa.so.0	_ZN12KApplication4KAppE
librpm	/usr/lib/librpmdb-4.0.4.so	hdrVec
sphinx3	/usr/lib/libs3audio.so.0	log10
sphinx3	/usr/lib/libs3decoder.so.0	glist_add_int32
seahorse	/usr/lib/libseahorse-internal.so.0	g_ascii_table
libfftw	/usr/lib/libsfftw_threads.so.2	fftw_die
libldap	/usr/lib/libslapi-2.2.so.7	slap_schema
libsmapi	/usr/lib/libsmapi.so.2.5	months_ab
libucd-snmp	/usr/lib/libsnmp.so.5	EVP_DigestInit
libfftw	/usr/lib/libsrfftw.so.2	fftw_die
bigloo-lib-srfi1	/usr/lib/libsrfi-1_s.so	BGl_pairzf3zd2envz21zz__r4_pairs_and_lists_6_3z00
libinn	/usr/lib/libstorage.so.2	HISlookup
libsvg	/usr/lib/libsvg.so.1	png_set_gray_1_2_4_to_8
subversion-perl	/usr/lib/libsvn_swig_perl-1.so.0	svn_swig_pl_get_current_pool
swig-runtime-php	/usr/lib/libswigphp4.so	compiler_globals
swig-runtime-perl	/usr/lib/libswigpl.so	Perl_sv_free
swig-runtime-python	/usr/lib/libswigpy.so	_Py_NoneStruct
swig-runtime-ruby	/usr/lib/libswigrb.so	rb_cSymbol
swig-runtime-tcl	/usr/lib/libswigtcl8.so	Tcl_TraceVar
libtheora	/usr/lib/libtheora.so.0	oggpackB_readinit
glibc-devel	/usr/lib/libthread_db.so	ps_pglobal_lookup
libtolua4	/usr/lib/libtolua.so.4	lua_insert
libtolua5	/usr/lib/libtolua.so.5	lua_insert
libtunepimp	/usr/lib/libtunepimp.so.2	uncompress
graphviz	/usr/lib/libtwopigen.so.0	E_weight
vips	/usr/lib/libvipsCC.so	g_thread_use_default_impl
libvisual	/usr/lib/libvisual.so.0	pthread_create
libwv2	/usr/lib/libwv2.so.1	_ZSt4cerr
libwvstreams	/usr/lib/libwvbase-4.0.so	_ZN15WvHashTableBaseC2Ej
w3c-libwww	/usr/lib/libwwwapp.so.0	HTMIMEFooter
w3c-libwww	/usr/lib/libwwwcache.so.0	WWW_TraceFlag
w3c-libwww	/usr/lib/libwwwinit.so.0	HTPrompt
w3c-libwww	/usr/lib/libwwwmime.so.0	HTBlackHoleConverter
w3c-libwww	/usr/lib/libwwwmux.so.0	WWW_TraceFlag
w3c-libwww	/usr/lib/libwwwssl.so.0	HTPEP_beforeFilter
w3c-libwww	/usr/lib/libwwwstream.so.0	WWW_TraceFlag
wxGTK-contrib-stc	/usr/lib/libwx_gtk_stc-2.4.so.0	_ZN12wxWindowBase13sm_eventTableE
wxGTK-contrib-xrc	/usr/lib/libwx_gtk_xrc-2.4.so.0	_ZTV10wxMenuBase
libxdelta2	/usr/lib/libxdelta.so.2	eventdelivery_handle_to_string
xffm	/usr/lib/libxffm_actions.so.1	tree_details
xffm	/usr/lib/libxffm_on_demand.so.1	g_strdup_printf
xffm	/usr/lib/libxffm_secondary.so.1	g_str_hash
xffm	/usr/lib/libxffm_tubo.so.1	g_strdup_printf
libxfsm	/usr/lib/libxfsm-4.2.so.0	gdk_display
w3c-libwww	/usr/lib/libxmlparse.so.0	XmlInitEncodingNS
xmp-common	/usr/lib/libxmp.so	dlerror
libxsldbg	/usr/lib/libxsldbg.so.3	xmlMalloc
libzvbi	/usr/lib/libzvbi-chains.so.0	dlsym
gnome-libs	/usr/lib/libzvt.so.2	gdk_root_window
AfterStep	/usr/X11R6/lib/libAfterBase.so	XFreePixmap
AfterStep	/usr/X11R6/lib/libAfterConf.so	dpy
AfterStep	/usr/X11R6/lib/libAfterImage.so	string_compare
xorg-x11-devel	/usr/X11R6/lib/libdmx.so	XextAddDisplay
xorg-x11-libs	/usr/X11R6/lib/libdmx.so.1	XextAddDisplay
xorg-x11-devel	/usr/X11R6/lib/libdpstk.so	ceil
xorg-x11-libs	/usr/X11R6/lib/libdpstk.so.1	ceil
libWINGs	/usr/X11R6/lib/libExtraWINGs.so.0	WMViewRealizedNotification
libxforms	/usr/X11R6/lib/libflimage.so.1	fl_fget2LSBF
XFree86-server-common	/usr/X11R6/lib/libfont.so.1	serverClient
libxforms	/usr/X11R6/lib/libformsGL.so.1	fl_current_form
libxforms	/usr/X11R6/lib/libforms.so.1	ceil
libgle	/usr/X11R6/lib/libgle.so.3	glBegin
xorg-x11-devel	/usr/X11R6/lib/libGLw.so	xmPrimitiveClassRec
xorg-x11-mesagl	/usr/X11R6/lib/libGLw.so.1	xmPrimitiveClassRec
xorg-x11-drv-i8xx	/usr/X11R6/lib/libI810XvMC.so.1	_xvmc_create_context
xorg-x11-devel	/usr/X11R6/lib/libOSMesa.so	sin
xorg-x11-mesagl	/usr/X11R6/lib/libOSMesa.so.4	sin
xorg-x11-drv-via	/usr/X11R6/lib/libviaXvMC.so.1	_xvmc_create_context
libWINGs	/usr/X11R6/lib/libWINGs.so.2	WMStringPointerHashCallbacks
libWINGs	/usr/X11R6/lib/libWMaker.so.1	XSetTextProperty
WSoundServer	/usr/X11R6/lib/libwsound.so.1	WMIsPLDictionary
xorg-x11-devel	/usr/X11R6/lib/libxf86config.so	ceil
libxorgconfig	/usr/X11R6/lib/libxf86config.so.6	ceil
xorg-x11-devel	/usr/X11R6/lib/libxkbui.so	cos
xorg-x11-libs	/usr/X11R6/lib/libxkbui.so.1	cos
libXlt	/usr/X11R6/lib/libXlt.so.0	xmPrimitiveWidgetClass
xorg-x11-devel	/usr/X11R6/lib/libXvMCW.so	XFree
xorg-x11-libs	/usr/X11R6/lib/libXvMCW.so.1	XFree
xorg-x11-devel	/usr/X11R6/lib/libXxf86rush.so	XSync
xorg-x11-libs	/usr/X11R6/lib/libXxf86rush.so.1	XSync

Какие будут мнения?  Что будем делать?  Стоит ли уже развешивать баги?

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

Re: [devel] RFC: test-libs

[Dmitry V. Levin]

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

Hi,

On Thu, Jun 16, 2005 at 02:37:23AM +0400, Alexey Tourbin wrote:
[правильные мысли о вреде незамкнутых разделяемых библиотек]
> Для обнаружения "не замкнутых" библиотек предлагается создать пакет
> test-libs, который будет собираться в среде, в которой установлены все
> или почти все разделяемые библиотеки.

Мне кажется более логичным определять такие библиотеки во время сборки
пакета, примерно на той же стадии, что и проверка RPATH.
Это, возможно, сложнее реализовать, но зато потом проще использовать.
Или нет?

[...]
> libconsole-tools	/lib/libcfont.so.0	unimapdesc_addpair
> libconsole-tools	/lib/libconsole.so.0	utf8_to_ucs2

Как оно вообще работает?

> samba-common	/lib/libnss_wins.so	yperr_string

Значит, libnss_wins нерабочий.

> glibc-core	/lib/libthread_db-1.0.so	ps_pglobal_lookup

Так и должно быть, эти символы живут в gdb.
P.S. А почему оно в /lib?

> libbfd	/usr/lib/libbfd-2.15.94.0.2.2.so	_sch_istable

bfd не слинковано с -liberty.

> librpm	/usr/lib/librpmdb-4.0.4.so	hdrVec

ldd -r не жалуется.  Бага в скрипте?

[множество криво собранных пакетов]
> Какие будут мнения?  Что будем делать?  Стоит ли уже развешивать баги?

Думаю, что пора делать 90% пакетов этого списка несобирающимися.
А то что-то Сизиф больно толстый и чрезмерно кривой стал.


-- 
ldv

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

Re: [devel] RFC: test-libs

[Dmitry V. Levin]

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

On Thu, Jun 16, 2005 at 03:22:18AM +0400, Dmitry V. Levin wrote:
> Hi,
> 
> On Thu, Jun 16, 2005 at 02:37:23AM +0400, Alexey Tourbin wrote:
> [правильные мысли о вреде незамкнутых разделяемых библиотек]
> > Для обнаружения "не замкнутых" библиотек предлагается создать пакет
> > test-libs, который будет собираться в среде, в которой установлены все
> > или почти все разделяемые библиотеки.
> 
> Мне кажется более логичным определять такие библиотеки во время сборки
> пакета, примерно на той же стадии, что и проверка RPATH.
> Это, возможно, сложнее реализовать, но зато потом проще использовать.

Алгоритм примерно такой:
- в /usr/lib/rpm/verify-elf, после того как вычислен RPATH;
- к вычисленному значению добавляется архитектурно-зависимый путь поиска
  библиотек (%_libdir:/%_lib);
- к вычисленному значению добавляется вывод от libtool-ldconfig-dump;
- к полученному списку добавляется в начало он же, но с префиксом
  %buildroot для каждого элемента;
- получившийся список используется в качестве LD_LIBRARY_PATH для "ldd -r";
- ошибки, найденные ldd, считаются фатальными, если только ещё не
  придуманный параметр для %_verify_elf_method не отключает эту проверку.


-- 
ldv

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

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 03:46:46AM +0400, Dmitry V. Levin wrote:
> Алгоритм примерно такой:
> - в /usr/lib/rpm/verify-elf, после того как вычислен RPATH;
> - к вычисленному значению добавляется архитектурно-зависимый путь поиска
>   библиотек (%_libdir:/%_lib);
> - к вычисленному значению добавляется вывод от libtool-ldconfig-dump;

$ libtool-ldconfig-dump
zsh: command not found: libtool-ldconfig-dump
$

> - к полученному списку добавляется в начало он же, но с префиксом
>   %buildroot для каждого элемента;

Как всё сложно...  Мне кажется, если просто написать
LD_LIBRARY_PATH=$RPM_BUILD_ROOT/lib:$RPM_BUILD_ROOT/usr/lib:$RPM_BUILD_ROOT/usr/X11R6/lib

то, по идее, сойдёт (для i586).

> - получившийся список используется в качестве LD_LIBRARY_PATH для "ldd -r";
> - ошибки, найденные ldd, считаются фатальными, если только ещё не
>   придуманный параметр для %_verify_elf_method не отключает эту проверку.

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

Re: [devel] Re: RFC: test-libs

[Dmitry V. Levin]

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

On Thu, Jun 16, 2005 at 04:43:32AM +0400, Alexey Tourbin wrote:
> $ libtool-ldconfig-dump
> zsh: command not found: libtool-ldconfig-dump
> $

$ rpmquery -f /usr/bin/libtool-ldconfig-dump 
libtool-common-0.2-alt1

> > - к полученному списку добавляется в начало он же, но с префиксом
> >   %buildroot для каждого элемента;
> 
> Как всё сложно...  Мне кажется, если просто написать
> LD_LIBRARY_PATH=$RPM_BUILD_ROOT/lib:$RPM_BUILD_ROOT/usr/lib:$RPM_BUILD_ROOT/usr/X11R6/lib
> 
> то, по идее, сойдёт (для i586).

Я описал алгоритм, с результатом работы которого сложно спорить. :)
Его не так сложно реализовать, между прочим, даже средствами shell'а.


-- 
ldv

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

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 04:52:18AM +0400, Dmitry V. Levin wrote:
> Я описал алгоритм, с результатом работы которого сложно спорить. :)
> Его не так сложно реализовать, между прочим, даже средствами shell'а.

Алгоритм должен учитывать одну маленькую особенность: при сборке
собственно glibc у ldd будет проблема с LD_LIBRARY_PATH; т.е. ldd
придётся запускать новым линкером.  По этим граблям недавно ходили.

> -- 
> ldv

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

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 03:22:18AM +0400, Dmitry V. Levin wrote:
> [правильные мысли о вреде незамкнутых разделяемых библиотек]
> > Для обнаружения "не замкнутых" библиотек предлагается создать пакет
> > test-libs, который будет собираться в среде, в которой установлены все
> > или почти все разделяемые библиотеки.
> 
> Мне кажется более логичным определять такие библиотеки во время сборки
> пакета, примерно на той же стадии, что и проверка RPATH.
> Это, возможно, сложнее реализовать, но зато потом проще использовать.
> Или нет?

У нас RPM выполняет несколько несвойственные ему функции (policy
enforcement).  Это примерно как если бы gcc по умолчанию работал
в режиме -Wall -Werror.  Не знаю, хорошо это или плохо. :)

> > Какие будут мнения?  Что будем делать?  Стоит ли уже развешивать баги?
> Думаю, что пора делать 90% пакетов этого списка несобирающимися.
> А то что-то Сизиф больно толстый и чрезмерно кривой стал.

Кстати, проверка на стадии сборки пакета -- это не то же самое, что
проверка уже собранного пакета!  Собранный пакет может бинарно
отличаться от пакета в репозитарии, в том числе и по линковке/символам.

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

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

Re: [devel] Re: RFC: test-libs

[Dmitry V. Levin]

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

On Thu, Jun 16, 2005 at 03:56:01AM +0400, Alexey Tourbin wrote:
> On Thu, Jun 16, 2005 at 03:22:18AM +0400, Dmitry V. Levin wrote:
> > [правильные мысли о вреде незамкнутых разделяемых библиотек]
> > > Для обнаружения "не замкнутых" библиотек предлагается создать пакет
> > > test-libs, который будет собираться в среде, в которой установлены все
> > > или почти все разделяемые библиотеки.
> > 
> > Мне кажется более логичным определять такие библиотеки во время сборки
> > пакета, примерно на той же стадии, что и проверка RPATH.
> > Это, возможно, сложнее реализовать, но зато потом проще использовать.
> > Или нет?
> 
> У нас RPM выполняет несколько несвойственные ему функции (policy
> enforcement).  Это примерно как если бы gcc по умолчанию работал
> в режиме -Wall -Werror.  Не знаю, хорошо это или плохо. :)

Ничего, все уже привыкли. :)

> > > Какие будут мнения?  Что будем делать?  Стоит ли уже развешивать баги?
> > Думаю, что пора делать 90% пакетов этого списка несобирающимися.
> > А то что-то Сизиф больно толстый и чрезмерно кривой стал.
> 
> Кстати, проверка на стадии сборки пакета -- это не то же самое, что
> проверка уже собранного пакета!  Собранный пакет может бинарно
> отличаться от пакета в репозитарии, в том числе и по линковке/символам.

Ну и что?  Собранный пакет совпадает с собираемым по окончании сборки
при условии успешности сборки.

> Поэтому сам факт успешной пересборки пакета ещё не раскрывает всей
> правды об этом пакете. :)

Достаточно просто установить его в пустую систему
(hsh --initroot, hsh-install victim) и прогнать тесты типа "ldd -r".

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

И что делать с полученной информацией?


-- 
ldv

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

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 04:27:28AM +0400, Dmitry V. Levin wrote:
> > Кстати, проверка на стадии сборки пакета -- это не то же самое, что
> > проверка уже собранного пакета!  Собранный пакет может бинарно
> > отличаться от пакета в репозитарии, в том числе и по линковке/символам.
> 
> Ну и что?  Собранный пакет совпадает с собираемым по окончании сборки
> при условии успешности сборки.

Не понял.  Допустим, у нас в репозитарии уже полгода лежит
lib%name-%version-alt1.i586.rpm.  Мы берём
lib%name-%version-alt1.src.rpm и скармливаем его роботу в целях
тестирования; теперь в ~/build/repo лежит более свежая сборка
lib%name-%version-alt1.i586.rpm.  Спрашивается: что общего у этих
двух сборок?  В общем случае, ничего общего.  Потому что сборочная
среда + версии BuildRequires с тех пор изменились.  Если просто
переложить более свежую сборку в сизиф, то что-нибудь может сломаться.
Но мы об этом ничего не знаем.

В сизифе есть такая же проблема, как при сборке gcc: если бы сизиф мог
собирать сам себя в несколько проходов, то результаты первых двух
проходов, вероятно, отличались бы.

> > После успешной пересборки нужно распаковать
> > свежесобранный пакет и пакет из репозатария; и провести ряд проверок
> > на идентичность, в т.ч. на бинарную совместимость.
> 
> И что делать с полученной информацией?

Хм.  Занести в базу данных. :)

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

[devel] [POLICY] P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Michael Shigorin]

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

On Thu, Jun 16, 2005 at 03:56:01AM +0400, Alexey Tourbin wrote:
> > Или нет?
> У нас RPM выполняет несколько несвойственные ему функции
> (policy enforcement).  Это примерно как если бы gcc по
> умолчанию работал в режиме -Wall -Werror.  Не знаю, хорошо это
> или плохо. :)

Это плохо постольку, поскольку полиси в существенной степени
нигде не зафиксированы.

	При этом на существенно разные по критичности и
	поддерживаемости компоненты Sisyphus налагаются
	одинаковые требования.  Выходит прокрустово ложе.

Есть предложение обязать вводящих полиси фиксировать их хотя бы
на том же wiki, если не в документации пакета, который выполняет
проверку и/или enforcement; если Sisyphus собирается
масштабироваться (а как общественный проект -- он обязан быть
достаточно разным), следует реализовать различие критичности
проверок для различных компонент.

Есть мнение, что часть этих работ уже выполнена в рамках проектов
incominger и prometeus, при этом (похоже) имела место некоторая
дубликация.  Хорошо бы помочь их авторам скоординироваться и/или
интегрировать код.

> > > Какие будут мнения?  Что будем делать?  Стоит ли уже
> > > развешивать баги?
> > Думаю, что пора делать 90% пакетов этого списка несобирающимися.
> > А то что-то Сизиф больно толстый и чрезмерно кривой стал.

Дим, а может, пора ALT начинать не толстеть, а взрослеть и для
начала всё те же правила игры публиковать?  А то забава
раскладыванием подводных грабель -- штука такая,
посмешит-посмешит да и надоест.

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

А китайское:

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

Проект с неявными правилами неприемлемости работы участников
обречён на маргинализацию и участь цехов.
---

PS: рекомендую _прочитать_ вчерашнюю ссылку на newsforge и
подумать про перфекционизм.  Он уместен разве что в SRPMS.perfect.
:)

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

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

Re: [devel] [POLICY] P: разделение критичности проверок для base..contrib

[Dmitry V. Levin]

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

On Thu, Jun 16, 2005 at 08:16:16AM +0300, Michael Shigorin wrote:
> > > > Какие будут мнения?  Что будем делать?  Стоит ли уже
> > > > развешивать баги?
> > > Думаю, что пора делать 90% пакетов этого списка несобирающимися.
> > > А то что-то Сизиф больно толстый и чрезмерно кривой стал.
> 
> Дим, а может, пора ALT начинать не толстеть, а взрослеть и для
> начала всё те же правила игры публиковать?  А то забава
> раскладыванием подводных грабель -- штука такая,
> посмешит-посмешит да и надоест.

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


-- 
ldv

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

[devel] Re: [POLICY] P: разделение критичности проверок для base..contrib

[Michael Shigorin]

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

On Thu, Jun 16, 2005 at 03:30:38PM +0400, Dmitry V. Levin wrote:
> Я не знаю, что пора начинать ALT.  Но лично мне Сизиф в его
> нынешнем виде не очень удобен, и с каждой неделей лично мне он
> всё меньше и меньше подходит по качеству.

А ты его весь применяешь? (вопрос риторический :)

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

Вот давай так и сделаем.  В конце концов, на то он и contrib.

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

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

[devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 08:16:16AM +0300, Michael Shigorin wrote:
> > У нас RPM выполняет несколько несвойственные ему функции
> > (policy enforcement).  Это примерно как если бы gcc по
> > умолчанию работал в режиме -Wall -Werror.  Не знаю, хорошо это
> > или плохо. :)
> 
> Это плохо постольку, поскольку полиси в существенной степени
> нигде не зафиксированы.

Полиси пусть kirill@ пишет. :)

> 	При этом на существенно разные по критичности и
> 	поддерживаемости компоненты Sisyphus налагаются
> 	одинаковые требования.  Выходит прокрустово ложе.

Это "проходные" требования снизу.  Требования сверху ограничены только
фантазией maintainer'а.  Предлагается установить достаточно высокую
планку прохождения пакетов в сизиф.  И время от времени её поднимать.
Будет встряска от застоя. :)

> Есть предложение обязать вводящих полиси фиксировать их хотя бы
> на том же wiki, если не в документации пакета, который выполняет
> проверку и/или enforcement; если Sisyphus собирается

Есть языковая проблема: если в рассылках словечки типа "слинковаться" --
это techspeak, то для документации это уже не катит.  Может по-английски
полиси писать?  Будет одно серьезное преимущество: весь остальной мир
узнает, какие у нас здесь ценные идеи бродят. :)

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

Проверка ELF'ов достаточно критична.  Некритичные компоненты должны
быть noarch -- с них и спросу никакого нет.

По поводу масштабирования, субъективное мнение: никакого масштабирования
в ближайшем будущем не будет, лучше попытаться всеми силами вырваться
вперед.  Грубо говоря, чтобы на вопрос "чем это лучше Fedora Core" можно
было с чистой совестью ответить: "всем" (это, кстати, предписывает
следить за pserver:anonymous@cvs.fedora.redhat.com:/cvs/dist :).

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

> Есть мнение, что часть этих работ уже выполнена в рамках проектов
> incominger и prometeus, при этом (похоже) имела место некоторая
> дубликация.  Хорошо бы помочь их авторам скоординироваться и/или
> интегрировать код.

Подробнее: какой именно код дублируется?

> Дим, а может, пора ALT начинать не толстеть, а взрослеть и для
> начала всё те же правила игры публиковать?  А то забава
> раскладыванием подводных грабель -- штука такая,
> посмешит-посмешит да и надоест.

Для RPM нужен legacy mode -- чтобы при сборке пакетов в частном
порядке не приходилось вникать в особенности ALT полиси.

Более серьезная претензция как раз по части .la файлов -- не собираются
KDE'шные приложения без хака на configure и т.п.  Если совместимости на
уровне RPM никто не гарантировал, то несовместимость на уровне GNU
autotools -- это уже некий показатель.

> Дистрибутив с невнятным позиционированием не может быть успешен
> коммерчески и не может быть интересен как платформа.

Долой дистрибутивы!  Даешь альтернативный формат выпуска свободного
софта!

> Проект с неявными правилами неприемлемости работы участников
> обречён на маргинализацию и участь цехов.

Проект и так уже маргинализован, один из кругов маргинализации
(маргинальности?) -- языковой.  С другой стороны, маленькие проекты
легче поддаются встряске.

> PS: рекомендую _прочитать_ вчерашнюю ссылку на newsforge и
> подумать про перфекционизм.  Он уместен разве что в SRPMS.perfect.
> :)

Да прочитал.  Вот несколько ошибок мы вчера нашли -- это хорошо или
плохо?  Например, нерабочий libnss_wins.  Это какую пользовательскую
базу нужно иметь, чтобы дождаться от тестеров-волонтёров
квалифицированного багрепорта по этому поводу?  И какая у нас
пользовательская база имеется и сколько тестеров-волонтёров тестируют
в репозитарии специфические фичи.  Очень важный вопрос.

Так вот, просто предлагается ликвидировать целый класс потенциальных
ошибок.  Перфекционизм это или нет, я не знаю.

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [050616 16:25]:
> Более серьезная претензция как раз по части .la файлов -- не собираются
> KDE'шные приложения без хака на configure и т.п.  Если совместимости на
> уровне RPM никто не гарантировал, то несовместимость на уровне GNU
> autotools -- это уже некий показатель.
Это не "несовместимость на уровне GNU autotools", а
"несовместимость на уровне использования GNU autotools не по
назначению".  Лично я считаю это плюсом, а не минусом.

-- 
Regards, Sir Raorn.
-------------------
С каких это пор запрещается желать странного?
		-- slava in devel@

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

[devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 05:40:42PM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [050616 16:25]:
> > Более серьезная претензция как раз по части .la файлов -- не собираются
> > KDE'шные приложения без хака на configure и т.п.  Если совместимости на
> > уровне RPM никто не гарантировал, то несовместимость на уровне GNU
> > autotools -- это уже некий показатель.

> Это не "несовместимость на уровне GNU autotools", а
> "несовместимость на уровне использования GNU autotools не по
> назначению".  Лично я считаю это плюсом, а не минусом.

Однако же это приводит к следующей ситуации: пользователь В.В.Пупкин
скачивает тарболл, запускает ./configure и получает недиагностируемую
ошибку.  Я считаю это серьезным недостатком "открытой" платформы.

Пользователь В.В.Пупкин потом будет всем рассказывать, что в Альте
сломаны GNU autotools, и будет отчасти прав.

То, что у всех работает, должно и у нас работать, пусть это даже
называется legacy mode и не является достаточным основанием для
включения результата в сизиф.

-- 
На основании этого можно сделать очевидные выводы:
+ нам удобно, чтобы чужие spec-файлы у нас работали (хотя бы для удобства
  подготовки своего spec-файла);
+ нам все равно, будут ли наши spec-файлы работать где-либо еще.
                -- ldv in sisyphus@

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Alexey Rusakov]

On 16.06.2005 18:30, Alexey Tourbin wrote:
>Однако же это приводит к следующей ситуации: пользователь В.В.Пупкин
>скачивает тарболл, запускает ./configure и получает недиагностируемую
>ошибку.  Я считаю это серьезным недостатком "открытой" платформы.
>
>Пользователь В.В.Пупкин потом будет всем рассказывать, что в Альте
>сломаны GNU autotools, и будет отчасти прав.
>
>То, что у всех работает, должно и у нас работать, пусть это даже
>называется legacy mode и не является достаточным основанием для
>включения результата в сизиф.
>  
По-моему, разумно будет это разрулить примерно так: в Мастере собираем в 
этом самом legacy mode (это же более слабые ограничения, поэтому ничего 
не должно сломаться, так?), а в Сизифе - ну извините, товарищ Пупкин 
должен был знать, на что идет, пересаживаясь на Сизиф.

-- 
  Alexey "Ktirf" Rusakov

[devel] Re: P: разделение критичности проверок для base..contrib

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 06:39:23PM +0400, Alexey Rusakov wrote:
> On 16.06.2005 18:30, Alexey Tourbin wrote:
> >Однако же это приводит к следующей ситуации: пользователь В.В.Пупкин
> >скачивает тарболл, запускает ./configure и получает недиагностируемую
> >ошибку.  Я считаю это серьезным недостатком "открытой" платформы.
> >
> >Пользователь В.В.Пупкин потом будет всем рассказывать, что в Альте
> >сломаны GNU autotools, и будет отчасти прав.
> >
> >То, что у всех работает, должно и у нас работать, пусть это даже
> >называется legacy mode и не является достаточным основанием для
> >включения результата в сизиф.
> > 
> По-моему, разумно будет это разрулить примерно так: в Мастере собираем в 
> этом самом legacy mode (это же более слабые ограничения, поэтому ничего 
> не должно сломаться, так?), а в Сизифе - ну извините, товарищ Пупкин 
> должен был знать, на что идет, пересаживаясь на Сизиф.

По пунктам:

1) Нужен legacy mode для RPM, чтобы пользователь В.В.Пупкин мог собирать
старые/чужие/другие rpm пакеты, которые не соответствуют текущему
ALT полиси: `rpm --legacy redhat-pacakge.src.rpm'.  В конце концов, ALT
полиси для сборки RPM пакетов является обязательной только для сизифа,
но не для производных от него продуктов/систем.

2) configure скрипты должны работать.  Софт из тарболлов должен
собираться.

При этом не следует думать, что недиагностируемая ошибка configure
сподвигнет В.В.Пупкина на изучение GNU autotools и специфики ALT.
Все дидактические мотивы из процесса сборки софта нужно исключить.

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Sergey V Turchin]

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

В сообщении от Четверг 16 Июнь 2005 18:58 Alexey Tourbin написал(a):

[...]

> 2) configure скрипты должны работать.  Софт из тарболлов должен
> собираться.
KDE-шные уже сейчас не собираются по 2-м причинам:
отсутствие .la и ошибка линковки при unresolved символах.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Dmitry V. Levin]

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

On Thu, Jun 16, 2005 at 06:58:54PM +0400, Alexey Tourbin wrote:
> 1) Нужен legacy mode для RPM, чтобы пользователь В.В.Пупкин мог собирать
> старые/чужие/другие rpm пакеты, которые не соответствуют текущему
> ALT полиси: `rpm --legacy redhat-pacakge.src.rpm'.  В конце концов, ALT
> полиси для сборки RPM пакетов является обязательной только для сизифа,
> но не для производных от него продуктов/систем.

Я готов принять патч на /usr/lib/rpm/rpmpopt-4.0.4, который реализует
параметр --legacy.  Но проверять корректность этого патча я не буду.

> 2) configure скрипты должны работать.  Софт из тарболлов должен
> собираться.

Вот именно: софт из тарболлов должен собираться; если он не собирается,
жалуйтесь изготовителям тарболлов.


-- 
ldv

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Maxim Tyurin]

Dmitry V. Levin writes:
\scip
>> 2) configure скрипты должны работать.  Софт из тарболлов должен
>> собираться.
>
> Вот именно: софт из тарболлов должен собираться; если он не собирается,
> жалуйтесь изготовителям тарболлов.

И получите в ответ:
"Мы протестировали сборку на RedHat, SuSE, Debian, Gentoo.
у нас все работает - проблема в вашем дистрибутиве".

Проверено уже.
-- 

With Best Regards, Maxim Tyurin aka Bungarus
JID:	MrKooll@jabber.pibhe.com

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Dmitry V. Levin]

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

On Wed, Jun 22, 2005 at 04:22:31PM +0300, Maxim Tyurin wrote:
> Dmitry V. Levin writes:
> >> 2) configure скрипты должны работать.  Софт из тарболлов должен
> >> собираться.
> >
> > Вот именно: софт из тарболлов должен собираться; если он не собирается,
> > жалуйтесь изготовителям тарболлов.
> 
> И получите в ответ:
> "Мы протестировали сборку на RedHat, SuSE, Debian, Gentoo.
> у нас все работает - проблема в вашем дистрибутиве".
> 
> Проверено уже.

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


-- 
ldv

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Maxim Tyurin]

Dmitry V. Levin writes:

> On Wed, Jun 22, 2005 at 04:22:31PM +0300, Maxim Tyurin wrote:
>> Dmitry V. Levin writes:
>> >> 2) configure скрипты должны работать.  Софт из тарболлов должен
>> >> собираться.
>> >
>> > Вот именно: софт из тарболлов должен собираться; если он не собирается,
>> > жалуйтесь изготовителям тарболлов.
>> 
>> И получите в ответ:
>> "Мы протестировали сборку на RedHat, SuSE, Debian, Gentoo.
>> у нас все работает - проблема в вашем дистрибутиве".
>> 
>> Проверено уже.
>
> Надо уметь работать с upstream'ом, в том числе и со слабовменяемым.
> Тогда проблемы можно решать.
> В противном случае они правы - проблема в дистрибутиве, который не умеет
> работать с upstream'ом.

Я немного не понял....
Это пользователи должны уметь работать с upstream? Да еще со
слабовменяемым.

Насколько я понимаю тема была про пользователей у которых стандартное
./configure && make && make install 
не работает.
-- 

With Best Regards, Maxim Tyurin aka Bungarus
JID:	MrKooll@jabber.pibhe.com

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Dmitry V. Levin]

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

On Wed, Jun 22, 2005 at 05:32:44PM +0300, Maxim Tyurin wrote:
> Dmitry V. Levin writes:
> > On Wed, Jun 22, 2005 at 04:22:31PM +0300, Maxim Tyurin wrote:
> >> Dmitry V. Levin writes:
> >> >> 2) configure скрипты должны работать.  Софт из тарболлов должен
> >> >> собираться.
> >> >
> >> > Вот именно: софт из тарболлов должен собираться; если он не собирается,
> >> > жалуйтесь изготовителям тарболлов.
> >> 
> >> И получите в ответ:
> >> "Мы протестировали сборку на RedHat, SuSE, Debian, Gentoo.
> >> у нас все работает - проблема в вашем дистрибутиве".
> >> 
> >> Проверено уже.
> >
> > Надо уметь работать с upstream'ом, в том числе и со слабовменяемым.
> > Тогда проблемы можно решать.
> > В противном случае они правы - проблема в дистрибутиве, который не умеет
> > работать с upstream'ом.
> 
> Я немного не понял....
> Это пользователи должны уметь работать с upstream? Да еще со
> слабовменяемым.

Нет, это мантейнеры пакетов, которые во время сборки необоснованно требуют
для использования нестандартным образом lib*.la-файлов, должны уметь
работать с upstream'ом.


-- 
ldv

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

[devel] *.la и выпуск? (was: P: разделение критичности проверок для base..contrib)

[Michael Shigorin]

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

On Wed, Jun 22, 2005 at 06:37:05PM +0400, Dmitry V. Levin wrote:
> > Я немного не понял....  Это пользователи должны уметь
> > работать с upstream? Да еще со слабовменяемым.
> Нет, это мантейнеры пакетов, которые во время сборки
> необоснованно требуют для использования нестандартным образом
> lib*.la-файлов, должны уметь работать с upstream'ом.

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

PS: а реально ли по ключику, скажем, --with compat или даже
просто --with la вкатывать *.la (тут вот подсказывают --
возможно, профильтровав чуть про .a) в lib%name-devel-compat,
которые собирать в contrib для дистрибутивов?

Если в принципе реально и есть выделяемая база проблемных
библиотек -- мы можем попробовать потренироваться на
Contribs 3.0.

Если этого для сборки "среднестатистического тарбола, который
проверен на Fedora/SuSE/Debian/Gentoo" совсем-совсем мало, но
идея в принципе реализуемая (как компромисс с real-world needs
пользователей, не для разработки) -- давайте это здесь обсудим
или накидайте в меня почтой, закину на wiki и будем думать, 
что можно сделать или проще забить (TM).

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

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

Re: [devel] *.la и выпуск?

[Dmitry V. Levin]

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

On Thu, Jun 23, 2005 at 12:12:44PM +0300, Michael Shigorin wrote:
> On Wed, Jun 22, 2005 at 06:37:05PM +0400, Dmitry V. Levin wrote:
> > > Я немного не понял....  Это пользователи должны уметь
> > > работать с upstream? Да еще со слабовменяемым.
> > Нет, это мантейнеры пакетов, которые во время сборки
> > необоснованно требуют для использования нестандартным образом
> > lib*.la-файлов, должны уметь работать с upstream'ом.
> 
> В сумме получаем противоречие с "и так распухшим и кривым
> сизифом", не говоря уж о выпусках.
> 
> PS: а реально ли по ключику, скажем, --with compat или даже
> просто --with la вкатывать *.la (тут вот подсказывают --
> возможно, профильтровав чуть про .a) в lib%name-devel-compat,
> которые собирать в contrib для дистрибутивов?

Гораздо более реально делать 2 скрипта:
- который будет удалять все la-файлы, которые удалил бы rpmbuild;
- который будет восстанавливать все la-файлы, подлежащие удалению первым
  скриптом; это легко сделать, поскольку вся необходимая информация и так
  есть в системе.

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


-- 
ldv

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

[devel] Re: *.la и выпуск?

[Michael Shigorin]

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

On Thu, Jun 23, 2005 at 02:49:59PM +0400, Dmitry V. Levin wrote:
> > PS: а реально ли по ключику, скажем, --with compat или даже
> > просто --with la вкатывать *.la (тут вот подсказывают --
> > возможно, профильтровав чуть про .a) в lib%name-devel-compat,
> > которые собирать в contrib для дистрибутивов?
> Гораздо более реально делать 2 скрипта:
> - который будет удалять все la-файлы, которые удалил бы rpmbuild;
> - который будет восстанавливать все la-файлы, подлежащие
>   удалению первым скриптом; это легко сделать, поскольку вся
>   необходимая информация и так есть в системе.

А, ты ж это подчёркивал.

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

Можешь Жене направление подсказать?

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

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

Re: [devel] Re: *.la и выпуск?

[Alexey I. Froloff]

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

* Michael Shigorin <mike@> [050623 15:01]:
> > Но у меня есть более актуальные задачи, чем заниматься этими
> > скриптами.  Если кто-то хочет попрактиковаться в скриптовании,
> > может попробовать написать второй скрипт.
> Можешь Жене направление подсказать?
readelf -d | grep NEEDED и так далее.

-- 
Regards, Sir Raorn.
-------------------
Есть тут у меня возможность выпросить железные IP-телефоны
потестировать, но кошку с голосом мне никто не даст.
		-- alb in devel@

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

Re: [devel] *.la и выпуск? (was: P: разделение критичности проверок для base..contrib)

[Alexander Bokovoy]

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

On Thu, Jun 23, 2005 at 12:12:44PM +0300, Michael Shigorin wrote:
> On Wed, Jun 22, 2005 at 06:37:05PM +0400, Dmitry V. Levin wrote:
> > > Я немного не понял....  Это пользователи должны уметь
> > > работать с upstream? Да еще со слабовменяемым.
> > Нет, это мантейнеры пакетов, которые во время сборки
> > необоснованно требуют для использования нестандартным образом
> > lib*.la-файлов, должны уметь работать с upstream'ом.
> 
> В сумме получаем противоречие с "и так распухшим и кривым
> сизифом", не говоря уж о выпусках.
> 
> PS: а реально ли по ключику, скажем, --with compat или даже
> просто --with la вкатывать *.la (тут вот подсказывают --
> возможно, профильтровав чуть про .a) в lib%name-devel-compat,
> которые собирать в contrib для дистрибутивов?
Зачем? Речь выше идет о тех приложениях, которые используют .la-файлы не
во время сборки, а во время запуска самого приложения для подгрузки
плагинов.

Вот с авторами таких приложений надо работать.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

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

[devel] Re: *.la и выпуск? (was: P: разделение критичности проверок для base..contrib)

[Michael Shigorin]

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

On Thu, Jun 23, 2005 at 05:56:08PM +0400, Alexander Bokovoy wrote:
> > > > Я немного не понял....  Это пользователи должны уметь
> > > > работать с upstream? Да еще со слабовменяемым.
> > > Нет, это мантейнеры пакетов, которые во время сборки
> > > необоснованно требуют для использования нестандартным образом
> > > lib*.la-файлов, должны уметь работать с upstream'ом.
> > В сумме получаем противоречие с "и так распухшим и кривым
> > сизифом", не говоря уж о выпусках.
> Зачем? Речь выше идет о тех приложениях, которые используют
> .la-файлы не во время сборки, а во время запуска самого
> приложения для подгрузки плагинов.
> Вот с авторами таких приложений надо работать.

Выпал из контекста, но тогда _вне_ его (не уверен, что найду 
то, в контексте которого это думал и здесь оно было или в
sisyphus@):

> > PS: а реально ли по ключику, скажем, --with compat или даже
> > просто --with la вкатывать *.la (тут вот подсказывают --
> > возможно, профильтровав чуть про .a) в lib%name-devel-compat,
> > которые собирать в contrib для дистрибутивов?

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

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

[devel] Re: P: разделение критичности проверок для base..contrib

[Michael Shigorin]

On Thu, Jun 16, 2005 at 06:39:23PM +0400, Alexey Rusakov wrote:
> По-моему, разумно будет это разрулить примерно так: в Мастере
> собираем в этом самом legacy mode (это же более слабые
> ограничения, поэтому ничего не должно сломаться, так?), а в
> Сизифе - ну извините, товарищ Пупкин должен был знать, на что
> идет, пересаживаясь на Сизиф.

Кстати (отвлекаясь от технологических моментов) -- правда.

Выпуск должен работать и не компостировать мозг.  А вот сизиф --
это действительно лаборатория и имеет полное право.

Вот только реализуемо ли это?

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Anton Farygin]

Michael Shigorin wrote:

>On Thu, Jun 16, 2005 at 06:39:23PM +0400, Alexey Rusakov wrote:
>  
>
>>По-моему, разумно будет это разрулить примерно так: в Мастере
>>собираем в этом самом legacy mode (это же более слабые
>>ограничения, поэтому ничего не должно сломаться, так?), а в
>>Сизифе - ну извините, товарищ Пупкин должен был знать, на что
>>идет, пересаживаясь на Сизиф.
>>    
>>
>
>Кстати (отвлекаясь от технологических моментов) -- правда.
>
>Выпуск должен работать и не компостировать мозг.  А вот сизиф --
>это действительно лаборатория и имеет полное право.
>
>Вот только реализуемо ли это?
>  
>
Нет.
выпуск строится на базе Sisyphus, соответственно менять надо именно в 
нем, а не пересобирать потом все специально для дистрибутива

Rgds,
Rider

[devel] собираемость kde*tgz & Co на Sisyphus и выпусках?

[Michael Shigorin]

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

On Fri, Jun 17, 2005 at 10:23:36AM +0400, Anton Farygin wrote:
> >Вот только реализуемо ли это?
> Нет.

Я вообще-то Диму спрашивал, поскольку дело скорее в/около rpm.
Что "нет" по умолчанию, и так понятно.

> выпуск строится на базе Sisyphus, соответственно менять надо
> именно в нем, а не пересобирать потом все специально для
> дистрибутива

Это как раз понятно, вопрос в том, получится ли сделать такое
изменение для нуждающихся -- _дополнительным_ пакетом (будь то
alias rpm='/bin/rpm --legacy' в profile.d или ещё что
неинтрузивного).

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

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

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

[devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Michael Shigorin]

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

On Thu, Jun 16, 2005 at 04:22:40PM +0400, Alexey Tourbin wrote:
> > Это плохо постольку, поскольку полиси в существенной степени
> > нигде не зафиксированы.
> Полиси пусть kirill@ пишет. :)

Я ж не против, постараюсь и помочь.  Только скорее не "пишет", 
а всё-таки "записывает", насколько понимаю.

> Предлагается установить достаточно высокую планку прохождения
> пакетов в сизиф.  И время от времени её поднимать.

Юмор оценил.

Не так давно писал тут эссе про компании и волонтеров, не знаю,
читал ли кто.

> > Есть предложение обязать вводящих полиси фиксировать их хотя
> > бы на том же wiki, если не в документации пакета, который
> Есть языковая проблема: если в рассылках словечки типа
> "слинковаться" -- это techspeak, то для документации это уже не
> катит.

В своё время внести Sisyphus в список дистров на faq.a.r мне
отказали, мотивировав это вполне внятно.  Я, собственно, и не
собирался спорить, а пошёл тормошить wiki.sisyphus.ru.

Есть мнение (высказанное этоё весной в docs@), что поднимать
планку для документации по Sisyphus превыше актуальности
бессмысленно.

> Может по-английски полиси писать?  Будет одно серьезное
> преимущество: весь остальной мир узнает, какие у нас здесь
> ценные идеи бродят. :)

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

> > масштабироваться (а как общественный проект -- он обязан быть
> > достаточно разным), следует реализовать различие критичности
> > проверок для различных компонент.
> Проверка ELF'ов достаточно критична.  Некритичные компоненты
> должны быть noarch -- с них и спросу никакого нет.

Ты хотел сказать "contrib"?  С noarch спрос бывает ещё какой.

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

Зачем/как?

> Грубо говоря, чтобы на вопрос "чем это лучше Fedora Core" можно
> было с чистой совестью ответить: "всем"

Да ладно, хватает "works for me".

> Вперёд можно вырваться только за счет технологического
> превосходства.

Да нет, те же RH и SuSE IMVCO впереди исключительно за счёт
организационного превосходства.  Где-то на wiki есть мои
плевательства про их спеки, я уж не говорю про порезку пакетов 
и вагон всего прочего.

> > Есть мнение, что часть этих работ уже выполнена в рамках
> > проектов incominger и prometeus, при этом (похоже) имела
> > место некоторая дубликация.  Хорошо бы помочь их авторам
> > скоординироваться и/или интегрировать код.
> Подробнее: какой именно код дублируется?

Анализ пакета.  Как минимум процесс раздирания пакета на запчасти
-- точно. (речь не только о коде, но и о дубликации процессов)

> > Дим, а может, пора ALT начинать не толстеть, а взрослеть и
> > для начала всё те же правила игры публиковать?  А то забава
> > раскладыванием подводных грабель -- штука такая,
> > посмешит-посмешит да и надоест.
> Для RPM нужен legacy mode -- чтобы при сборке пакетов в частном
> порядке не приходилось вникать в особенности ALT полиси.

Ммм... это с отрывом большинства/всех проверок, не
предусмотренных в голом upstream?

> Более серьезная претензция как раз по части .la файлов -- не
> собираются KDE'шные приложения без хака на configure и т.п.
> Если совместимости на уровне RPM никто не гарантировал, то
> несовместимость на уровне GNU autotools -- это уже некий
> показатель.

Скажем так -- нигде эти несовместимости толком вместе не описаны.

> > Дистрибутив с невнятным позиционированием не может быть
> > успешен коммерчески и не может быть интересен как платформа.
> Долой дистрибутивы!  Даешь альтернативный формат выпуска
> свободного софта!

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

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

"...а оптимист говорит -- есть куда!" :]

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

> > PS: рекомендую _прочитать_ вчерашнюю ссылку на newsforge и
> > подумать про перфекционизм.  Он уместен разве что в
> > SRPMS.perfect.  :)
> Да прочитал.  Вот несколько ошибок мы вчера нашли -- это хорошо
> или плохо?  Например, нерабочий libnss_wins.  Это какую
> пользовательскую базу нужно иметь, чтобы дождаться от
> тестеров-волонтёров квалифицированного багрепорта по этому
> поводу?  И какая у нас пользовательская база имеется и сколько
> тестеров-волонтёров тестируют в репозитарии специфические фичи.
> Очень важный вопрос.

Так тут вторая сторона ордена -- какую надо иметь квалификацию,
чтобы откопать корень проблемы и порешать его?  Дима -- *Дима* --
вон как-то обошёлся в ответе без слова "тривиально".

> Так вот, просто предлагается ликвидировать целый класс
> потенциальных ошибок.  Перфекционизм это или нет, я не знаю.

Это хорошее дело, если для contrib оно не будет вменяться в
обязанность.  В зависимости от высоты планки для base и
прилежащих компонент -- _там_ вполне может.  По крайней мере 
я был бы за.

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

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

[devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 07:36:24PM +0300, Michael Shigorin wrote:
> > Предлагается установить достаточно высокую планку прохождения
> > пакетов в сизиф.  И время от времени её поднимать.
> Юмор оценил.

Это не совсем юмор, я действительно так думаю.  Собственно, если не
технологическое превосходство и не повышенное качество сборки пакетов,
плюс продуманность зависимостей и т.п. -- чем тогда Sisyphus, грубо
говоря, лучше Fedora Core?  По пользовательской базе и по количеству
тестеров-волонтёров Sisyphus всё-таки заметно проигрывает. :)  Значит,
нужно искать "другие" сильные стороны и пытаться их максимльно полно
реализовать, пробовать отчасти заменить ими то, чего нет.

> > По поводу масштабирования, субъективное мнение: никакого
> > масштабирования в ближайшем будущем не будет, лучше попытаться
> > всеми силами вырваться вперед.
> Зачем/как?

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

Последним крупным достижением по части технологии был hasher (2003),
последним крупным рывком, не очень удачно организованным -- удаление
*.la файлов, примерно в то же время.  Последним мелким достижением
стало появление rpm-build-perl-0.5 (Dec 06 2004). :)

Нужно постоянно что-то улучшать, выискивать новые (потенциальные) ошибки,
рассылать побольше спама и т.п. :)  Если же просто заворачивать новые
версии программ в rpm пакеты и отправлять их в incoming -- тогда это
"застой" какой-то получается, стагнация.  Зачем это нужно?  Новые версии
программ можно и полу-автоматически собирать.  Вон в Мандриве есть
какой-то /usr/bin/rpmbuildupdate из пакета rpm-rebuilder:

rpmbuildupdate: download and rebuild the new version of a given srpm.

Id: 1463
Я как-то жене на пальцах объяснял, чем я тут время от времени занимаюсь:
скачиваю программы из разных мест и закачиваю их в ALT Linux; мне пока
решительно не понятно, почему эта нехитрая трансформация влечет за собой
юридические последствия. :)
                -- at in devel@
%

> > Грубо говоря, чтобы на вопрос "чем это лучше Fedora Core" можно
> > было с чистой совестью ответить: "всем"
> Да ладно, хватает "works for me".

Нужно пытаться делать самое лучшее.
А иначе лучше ничего не делать и пользоваться тем, что уже есть.

> > Вперёд можно вырваться только за счет технологического
> > превосходства.
> Да нет, те же RH и SuSE IMVCO впереди исключительно за счёт
> организационного превосходства.  Где-то на wiki есть мои
> плевательства про их спеки, я уж не говорю про порезку пакетов 
> и вагон всего прочего.

Организационное превосходство -- это совсем другая тема.  Здесь есть
очень много вопросов и очень мало внятного было сказано.  "Нужно решить
проблему взаимодействия фирм и сообщества" -- "нужно решить проблему
голода в странах Африки и найти лекарство от рака".  Я для себя эту
проблему "решил" так: дистрибутивы ALT Linux меня не интересуют, потому
что это откусывание времени на тупиковую ветку развития с низкой отдачей
для сизифа.  (Здесь также актуальны вопросы критического количества
инсталляций, ради которого стоит поддерживать отдельную ветку,
платежеспособного спроса на поддержку и т.д.)

Со временем, наверное, что-то изменится.  Это не по моей части.

> Анализ пакета.  Как минимум процесс раздирания пакета на запчасти
> -- точно. (речь не только о коде, но и о дубликации процессов)

Надо посмотреть.  Посмотрю.

> > Для RPM нужен legacy mode -- чтобы при сборке пакетов в частном
> > порядке не приходилось вникать в особенности ALT полиси.
> Ммм... это с отрывом большинства/всех проверок, не
> предусмотренных в голом upstream?

Да.  Грубо говоря, чтобы значительная часть редхатовских src.rpm пакетов
собиралось; вернее, чтобы их сборка заканчивалась. :)

> > Более серьезная претензция как раз по части .la файлов -- не
> > собираются KDE'шные приложения без хака на configure и т.п.
> > Если совместимости на уровне RPM никто не гарантировал, то
> > несовместимость на уровне GNU autotools -- это уже некий
> > показатель.
> Скажем так -- нигде эти несовместимости толком вместе не описаны.

Несовместимость на уровне GNU autotools -- это вообще нонсенс,
ведь GNU autotools и предназначены в первую очередь для достижения
совместимости на всём и вся.  Ну я уже изложил "по пункатам".

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

Долой фирмы!  Даешь светлое будущее! :)

> Так вот как раз с языковым-то проще, когда особенности ясно
> собраны и понятно, что подсовывать переводчикам -- а в остальном
> годится типичная базарная документация с гугля. (ну, где-то)

С языком как раз плохо.  Население ex-USSR -- это примерно 200 млн.
человек, население планеты -- примерно 6 млрд.  То, что мы тут пишем,
в состоянии понять только 3% населения планеты, вернее, примерно такой
же процент потенциально заинтересованных разработчиков.

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

> Так тут вторая сторона ордена -- какую надо иметь квалификацию,
> чтобы откопать корень проблемы и порешать его?  Дима -- *Дима* --
> вон как-то обошёлся в ответе без слова "тривиально".

Не понял про "тривиально".  Но мы же здесь "хакеры", да?

> > Так вот, просто предлагается ликвидировать целый класс
> > потенциальных ошибок.  Перфекционизм это или нет, я не знаю.
> Это хорошее дело, если для contrib оно не будет вменяться в
> обязанность.  В зависимости от высоты планки для base и
> прилежащих компонент -- _там_ вполне может.  По крайней мере 
> я был бы за.

Я против понижения статуса contrib, ведь большинство пользователей
Sisyphus сейчас использует SRPMS.classic.  Если же удалить contrib
из настроек apt по умолчанию, то это спровоцирует дальнейшее падение
статуса contrib, сделает из него отстойник.

Собственно, я не понимаю, в чем проблема.  Сейчас будет добавлена новая
проверка, и робот будет слать спам.  Будет 5 месяцев на исправление.
Через 5 месяцев большая часть пакетов будет hopefully исправлена,
меньшая уйдёт в orphaned и затем hopefully сменит maintainer'ов.  То
есть через 5 месяцев мы сможем сказать, что такой-то класс потенциальных
проблем в сизифе исправлен.

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

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

[devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Michael Shigorin]

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

эхъ... "и тут Остапа понесло"

On Fri, Jun 17, 2005 at 12:30:23AM +0400, Alexey Tourbin wrote:
> Собственно, если не технологическое превосходство и не
> повышенное качество сборки пакетов, плюс продуманность
> зависимостей и т.п. -- чем тогда Sisyphus, грубо говоря, лучше
> Fedora Core?  По пользовательской базе и по количеству
> тестеров-волонтёров Sisyphus всё-таки заметно проигрывает. :)
> Значит, нужно искать "другие" сильные стороны и пытаться их
> максимльно полно реализовать, пробовать отчасти заменить ими
> то, чего нет.

Это... любую палку можно перегнуть, у любого баланса есть предел.

IMCO сильные стороны Sisyphus -- скорее в открытости сборочных
сред и технологий сборки решений вдобавок к тому, что ты сказал.

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

Что потиху в процессе :-)

> > > По поводу масштабирования, субъективное мнение: никакого
> > > масштабирования в ближайшем будущем не будет, лучше
> > > попытаться всеми силами вырваться вперед.
> > Зачем/как?
> Нужны очередные шаги по части улучшения сборки/тестирования
> пакетов, а также по части автоматического тестирования
> репозитария.

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

Соответственно можно повесить ещё сотню багов, а толку, если они
ещё год провисят нетронутыми?

> Последним крупным достижением по части технологии был hasher
> (2003), последним крупным рывком, не очень удачно
> организованным -- удаление *.la файлов, примерно в то же время.
> Последним мелким достижением стало появление rpm-build-perl-0.5
> (Dec 06 2004). :)

Ну, там где-то ещё питон перепахивали.  При всём окрестном горе
"нутром чую" (tm), что тоже дело хорошее. :-)

> Нужно постоянно что-то улучшать, выискивать новые
> (потенциальные) ошибки, рассылать побольше спама и т.п. :)

Не-а.

> > > Грубо говоря, чтобы на вопрос "чем это лучше Fedora Core"
> > > можно было с чистой совестью ответить: "всем"
> > Да ладно, хватает "works for me".
> Нужно пытаться делать самое лучшее.  А иначе лучше ничего не
> делать и пользоваться тем, что уже есть.

Критерии "самого лучшего" индивидуальны.  Не, я тебя понимаю 
и "для меня" то, что делаю -- действительно обычно "объективно"
самое лучшее, вот только нет смысла доказывать это в общем
случае. :-)

> > > Вперёд можно вырваться только за счет технологического
> > > превосходства.
> > Да нет, те же RH и SuSE IMVCO впереди исключительно за счёт
> > организационного превосходства.  Где-то на wiki есть мои
> > плевательства про их спеки, я уж не говорю про порезку пакетов 
> > и вагон всего прочего.
> Организационное превосходство -- это совсем другая тема.

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

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

Ну почему, всё далеко не так плохо.  В конце концов, если одна
фирма будет последовательно забивать на сообщество -- могут
найтись ещё одна-две. :-)

> Я для себя эту проблему "решил" так: дистрибутивы ALT Linux
> меня не интересуют, потому что это откусывание времени на
> тупиковую ветку развития с низкой отдачей для сизифа.

Как можно судить по backports@, я этой точки зрения не
придерживаюсь, ну да и спорить не буду.  Каждому своё.

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

Да, конечно.  И ещё один тривиальный -- доступности того же
сизифа.

> Долой фирмы!  Даешь светлое будущее! :)

На :-)

> С языком как раз плохо.  Население ex-USSR -- это примерно 200
> млн.  человек, население планеты -- примерно 6 млрд.  То, что
> мы тут пишем, в состоянии понять только 3% населения планеты,
> вернее, примерно такой же процент потенциально заинтересованных
> разработчиков.

Да нет, всё ещё на порядки хуже.  Или лучше.

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

Мне влом.  Пиши :-)

> > Так тут вторая сторона ордена -- какую надо иметь
> > квалификацию, чтобы откопать корень проблемы и порешать его?
> > Дима -- *Дима* -- вон как-то обошёлся в ответе без слова
> > "тривиально".
> Не понял про "тривиально".  Но мы же здесь "хакеры", да?

Кто как.  После появления docs@ как минимум одна явно иная роль
для join@ прибавилась.  Если кто-то заинтересован в переводчиках
и прочих артистических натурах -- это ещё две роли.  А ещё
контент-часть, по-хорошему.

И для некоторых из них даже "хакерские" лепестронные подписи,
наверное -- слишком много мороки ни о чём.

> Я против понижения статуса contrib, ведь большинство
> пользователей Sisyphus сейчас использует SRPMS.classic.

Я вот на днях заряжал vserver с ALM2.4 без contrib.
Планирую привести в привычку.

> Если же удалить contrib из настроек apt по умолчанию, то это
> спровоцирует дальнейшее падение статуса contrib, сделает из
> него отстойник.

Ну прям апокалиптические какие-то вещи.

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

> Собственно, я не понимаю, в чем проблема.

Подумай.  Собственно, одно дело -- мягко долбить темечко, причём
для contrib -- не роботом, а варнингами при сборке, и саавсем
другое -- unmet'ы генерить.

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

Кому -- procmail? (ну, шутка, типа -- сам-то читаю)

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

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Denis Smirnov]

On Fri, Jun 17, 2005 at 12:04:42AM +0300, Michael Shigorin wrote:

MS> Опять же субъективные наблюдения прямо сейчас говорят, что баланс
MS> надо ровнять в сторону тех, кто может исправлять проблемы --
MS> находящих _давно_ больше.

Есть группы багов которые _найти_ практически нереально без
автоматизированых тестов. Я помню как год назад, например, выискивал
статически слинкованые с libdb4 программы, то ещё удовольствие.

Идеальный подход, это когда сообщение об ошибке при сборке будет содержать
в себе ссылку на страничку wiki.sisyphus.ru, содержащую полное описание
проблемы, как её решить, или как отключить эту проверку. Благо всегда
можно полностью автоматически найти пакеты, где конкретная проверка
отключена, и попытаться их исправить.

MS> Соответственно можно повесить ещё сотню багов, а толку, если они
MS> ещё год провисят нетронутыми?

Если висит бага -- она может быть не закрыта. Если очередная сборка пакета
вдруг не соберётся у меня в хэшере я начну думать "а какого хрена?" и
попытаюсь таки это исправить. Наилучшим из способов, доступных при моей
квалификации, одновременно спрашивая в devel@ "а как это сделать _еще_
лучше" у более опытных товарищей.

MS> Подумай.  Собственно, одно дело -- мягко долбить темечко, причём
MS> для contrib -- не роботом, а варнингами при сборке, и саавсем
MS> другое -- unmet'ы генерить.

Может просто для contrib по-умолчанию _отключать_ отдельные проверки?

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

http://freesource.info

[devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Michael Shigorin]

On Fri, Jun 17, 2005 at 04:39:41AM +0400, Denis Smirnov wrote:
> MS> Опять же субъективные наблюдения прямо сейчас говорят, что баланс
> MS> надо ровнять в сторону тех, кто может исправлять проблемы --
> MS> находящих _давно_ больше.
> Есть группы багов которые _найти_ практически нереально без
> автоматизированых тестов. Я помню как год назад, например,
> выискивал статически слинкованые с libdb4 программы, то ещё
> удовольствие.

Я не говорю о том, что искать баги (и по возможности это
автоматизировать) не надо.  Но и не забываю "если вы будете
писать нам cron'ом, мы будем читать вас procmail'ом".

Бишь баланс между силами и средствами на поиске и исправлении
проблем -- важнее.

> Идеальный подход, это когда сообщение об ошибке при сборке
> будет содержать в себе ссылку на страничку wiki.sisyphus.ru,
> содержащую полное описание проблемы, как её решить, или как
> отключить эту проверку. Благо всегда можно полностью
> автоматически найти пакеты, где конкретная проверка отключена,
> и попытаться их исправить.

Ну, самодокументированность вообще хорошее свойство.

> MS> Подумай.  Собственно, одно дело -- мягко долбить темечко, причём
> MS> для contrib -- не роботом, а варнингами при сборке, и саавсем
> MS> другое -- unmet'ы генерить.
> Может просто для contrib по-умолчанию _отключать_ отдельные
> проверки?

А я о чём говорю? (правда, не отключать, но делать нефатальными
-- чтоб заметить было можно, но, например, вопросы TEXTREL после
повторного изучения темы никак не могу считать критическими)

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

[devel] Re: P: разделение критичности проверок для base..contrib

[Denis Smirnov]

Michael Shigorin wrote:

>Я не говорю о том, что искать баги (и по возможности это
>автоматизировать) не надо.  Но и не забываю "если вы будете
>писать нам cron'ом, мы будем читать вас procmail'ом".
>
>Бишь баланс между силами и средствами на поиске и исправлении
>проблем -- важнее.
>  
>
Бесспорно. Впорос лишь где он проходит.

>>Идеальный подход, это когда сообщение об ошибке при сборке
>>будет содержать в себе ссылку на страничку wiki.sisyphus.ru,
>>содержащую полное описание проблемы, как её решить, или как
>>отключить эту проверку. Благо всегда можно полностью
>>автоматически найти пакеты, где конкретная проверка отключена,
>>и попытаться их исправить.
>>    
>>
>Ну, самодокументированность вообще хорошее свойство.
>  
>
Кто бы спорил. Но даже с нынешними проверками надо долго иногда голову 
работать, что не так (это я про verify_elf, который хоть и не слишком 
часто, но вызывает вопросы).

>>MS> Подумай.  Собственно, одно дело -- мягко долбить темечко, причём
>>MS> для contrib -- не роботом, а варнингами при сборке, и саавсем
>>MS> другое -- unmet'ы генерить.
>>Может просто для contrib по-умолчанию _отключать_ отдельные
>>проверки?
>>    
>>
>А я о чём говорю? (правда, не отключать, но делать нефатальными
>-- чтоб заметить было можно, но, например, вопросы TEXTREL после
>повторного изучения темы никак не могу считать критическими)
>  
>
IMHO ситуация с ними сейчас правильная, если бы в сообщении об ошибке 
была ссылка на объяснение что это такое, с чем едят, почему вредно, как 
отключить это проверку нафиг.
До тех пор, пока мантейнер может легким движением руки отключить 
проверку -- эту проверку имеет смысл делать.

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Michael Shigorin]

On Fri, Jun 17, 2005 at 02:01:33PM +0400, Denis Smirnov wrote:
> >Бишь баланс между силами и средствами на поиске и исправлении
> >проблем -- важнее.
> Бесспорно. Впорос лишь где он проходит.

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

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Denis Smirnov]

On Fri, Jun 17, 2005 at 01:25:20PM +0300, Michael Shigorin wrote:

>>>Бишь баланс между силами и средствами на поиске и исправлении
>>>проблем -- важнее.
>> Бесспорно. Впорос лишь где он проходит.
MS> Не знаю.  Но боюсь, что дальнейший сдвиг в сторону поиска и при
MS> этом демотивации майнтейнеров может ненароком перешагнуть ещё
MS> одну ступеньку.

Что ты предлагаешь? У нас есть две проблемы, известные решения которых
друг с другом конфликтуют:

1. Сизиф становится не просто крив, а ужасен. Год назад я практически без
страха делал dist-upgrade средь бела дня на боевом сервере, даже зная что
простой в несколько часов будет стоить мне денег. 

Сейчас я боюсь делать dist-upgrade. Единственное где я его делаю ежедневно
-- мой ноутбук. И иногда при этом поминаю мантейнеров отдельных пакетов не
самыми тёплыми словами, и мне это не нравится.

Уровень оттестированности становится все хуже и хуже. А для меня лично
качество сборок ALT Team было одним из важнейших причин перехода на ALT.
Думаю я не один такой.

2. Мантейнеров надо мотивировать.

Если начинает зверствовать QA, то мантейнерам "не по кайфу". Если не
зверствовать, пользователям проще будет перейти на Debian (они вроде
начинают более вменяемую политику релизов пытаться проводить).

Пока я вижу такое решение:

1. QA должен не просто зверствовать, а таки зверствовать как истинные
маньяки. Но с одним маленьким ограничением -- мантейнерам сказал
"молчать!" (поставив соответствующую строчку, затыкающую конкретную
проверку в спеке), и робот заткнулся и больше не трогает.

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

3. Таки сделать единую систему для финансирования таких разовых правок.
Грубо говоря, если тысяча пользователей скинутся по 1$ и скажут -- Миша,
пожалуйста, приведи в порядок xmms (при том что работы там, как ты
говорил, не много) -- думаю это будет достаточной мотивацией, не правда
ли? 

В дополнение -- у нас есть серьёзная проблема. Sisyphus это проект _Team_,
но возможностью финансировать разработчиков компонент обладают только
несколько организаций. Мантейнеры-одиночки в принципе не могут кормиться
со своей мантейнерской работы. Даже если пакет _очень_ критичен для
дистрибутива. Да и не одиночки тоже не шибко -- сколько ты получаешь за
поддержку Apache? Что-то не заметно чтобы он у тебя был на первых местах
по важности в плане поддержки, и чтобы ты в него вкладывал много времени.
А ведь это одна из ключевых компонент дистрибутива. И ведь желающих у
тебя этот пакет позаимствовать почему-то не видно :)

Скажу ещё больше, я согласин с at@ в том, что _мне тоже_ лично не нужен
дистрибутив. Совсем-совсем не нужен. А более стабильный сизиф нужен. И я
даже платить за него готов. И если бы его стабильность была такова, что я
мог бы на боевом сервере поставить dist-upgrade в крон, уезжая на месяц в
отпуск без ноутбука, то сумма типа 100$/месяц показалась бы мне даже
смешной. А вот 50$ за коробку с дистрибутивом для меня раз в год много.
В том числе и потому, что меня не устраивает качество этой коробки (общее
_эмоциональное_ впечатление от 2.4 гораздо хуже чем от 2.2).

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

http://freesource.info

[devel] Re: P: разделение критичности проверок для base..contrib

[Michael Shigorin]

On Fri, Jun 17, 2005 at 03:36:53PM +0400, Denis Smirnov wrote:
> Что ты предлагаешь? У нас есть две проблемы, известные решения
> которых друг с другом конфликтуют:
> 1. Сизиф становится не просто крив, а ужасен. Год назад я
> практически без страха делал dist-upgrade средь бела дня на
> боевом сервере, даже зная что простой в несколько часов будет
> стоить мне денег. 

Это не "у нас", а "у тебя".  Я знаю только одного действительного
опытного, но при этом сорвиголову, который, не читая sisyphus@,
так делает.  И сам не делаю давно.

Развивай стабильный выпуск в backports, порой вливая в сизиф --
или у тебя масштаб фронта, где надо самое-самое последнее по
объективным причинам, и есть полсистемы?

А рассказывать сказки про "год назад деревья были зеленей" --
не надо, поскольку год назад что-то только что вышло и была
окрестность точки стабилизации.  Периодически [sic] это бывает.
Соответственно после следующего фриза будет где-то так же.
И после очередной дебардакизации -- опять щепки.

> Уровень оттестированности становится все хуже и хуже. А для
> меня лично качество сборок ALT Team было одним из важнейших
> причин перехода на ALT.  Думаю я не один такой.

Для меня -- тоже.  И именно из-за того, что хочется получше,
и пишу сейчас ровно то, что пишу.

Только я ещё/уже не настолько ^Wбезбашенный, чтобы не разделять
разработку и эксплуатацию.  Если кто-то верит в объединяемость 
этих полюсов или так и делает -- он рано или поздно стукнется 
в крепкие грабли и будет сидеть обиженным, в лучшем случае
прекрасно зная, что сам дурак.

Это данность.

> 2. Мантейнеров надо мотивировать.
> Если начинает зверствовать QA, то мантейнерам "не по кайфу".

Даже если не зверствовать (что может быть в фирме), а просто
задалбывать.  Восприятие-то тоже бывает разным.

> Если не зверствовать, пользователям проще будет перейти на
> Debian (они вроде начинают более вменяемую политику релизов
> пытаться проводить).

И Fedora тоже, ссылки сегодня в студии.

> Пока я вижу такое решение: 1. QA должен не просто зверствовать,
> а таки зверствовать как истинные маньяки.

Тьфу.

> Но с одним маленьким ограничением -- мантейнерам сказал
> "молчать!" (поставив соответствующую строчку, затыкающую
> конкретную проверку в спеке), и робот заткнулся и больше не
> трогает.

Да-да, и залить в сизиф расставлялку затычек. :-/

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

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

Вот это интереснее -- группировка /типичных проблем/.

> 3. Таки сделать единую систему для финансирования таких разовых
> правок.  Грубо говоря, если тысяча пользователей скинутся по 1$
> и скажут -- Миша, пожалуйста, приведи в порядок xmms (при том
> что работы там, как ты говорил, не много) -- думаю это будет
> достаточной мотивацией, не правда ли? 

Необязательно "1000 по $1", скорее "двое-трое скинутся
напильниками и перепилят инитскрипты трёх десятков зависших
пакетов после переезда на новую схему" и подобное.

Опять же моя позиция -- за качество должны платить те, кто в нём
нуждается.  И столько, на сколько их нужды тянут.

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

С волонтерами работает подход "с нами и вот так -- удобнее".
А не построить всех в шеренгу по полтора и бегом марш.

> В дополнение -- у нас есть серьёзная проблема. Sisyphus это
> проект _Team_, но возможностью финансировать разработчиков
> компонент обладают только несколько организаций.

Да.

> Мантейнеры-одиночки в принципе не могут кормиться со своей
> мантейнерской работы.

Теоретически могут, на практике если это происходит -- сбиваются
в команды/фирмы.

> Даже если пакет _очень_ критичен для дистрибутива. Да и не
> одиночки тоже не шибко -- сколько ты получаешь за поддержку
> Apache?

На предыдущей работе apache, mod_php, MySQL и PostgreSQL и были
тем, за работу чего я получал зряплату.  Плюс к тому, это
критичный сервис для нескольких более общественных проектов.

> Что-то не заметно чтобы он у тебя был на первых местах по
> важности в плане поддержки, и чтобы ты в него вкладывал много
> времени.

Открою страшную тайну -- самые любимые пакеты -- это те, которые
вообще не потребляют времени.  Потому как в сводках с разборки
Sisyphus они не фигурируют, в bugtraq@ не светятся, работают 
и каши не просят. :-)

> А ведь это одна из ключевых компонент дистрибутива.

На самом деле это действительно немного смешно, но как раз apache
в ALT Linux по жизни поддерживался исключительно волонтерами и
насколько знаю -- к коммерческим их проектам отношение имел 
в лучшем случае косвенное.

> И ведь желающих у тебя этот пакет позаимствовать почему-то не
> видно :)

Да, не видно.

> Скажу ещё больше, я согласин с at@ в том, что _мне тоже_ лично
> не нужен дистрибутив. Совсем-совсем не нужен. А более
> стабильный сизиф нужен. И я даже платить за него готов.

Слушай, вспомни мои высказывания в последнем забеге на тему 
"стабильного сизифа".  Хороший рабочий current -- да, наверное,
неплохо.  Но вот думать о поддерживаемости его _я_ не собираюсь,
поскольку упираться в то, что на данном конкретном тазу было на
скору руку заморожено невесть что потому, что на тестовом после
обновления взорвалось что-то критичное -- а тут дырка и надо бы
что-то с этим сделать -- не собираюсь.

Заведи где-нить какое-нить gentoo, поживи на этом, потом вернёмся 
к обсуждению.

BTW: есть мнение, что надо двигаться в сторону 18-месячного
интервала меджу выпусками (осень/весна) того, что вообще
рекомендуется для серверов.  А вот настольное -- действительно
раз в полгода выпускать.

> И если бы его стабильность была такова, что я мог бы на боевом
> сервере поставить dist-upgrade в крон, уезжая на месяц в отпуск
> без ноутбука, то сумма типа 100$/месяц показалась бы мне даже
> смешной.

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

Всё, что я могу сказать по сути -- это "надо .incoming" -- на
сейчас заблокировано проблемами в APT.  Решить их я не могу,
оценить стоимость решения -- тоже.

> А вот 50$ за коробку с дистрибутивом для меня раз в год много.

У тебя и так есть коробка, да и слить его тебе недолго.  Мне тоже.
Не передёргивай. (даже если я тоже считаю, что эта коробка ни
разу не оправдывает этих денег)

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Aleksey Novodvorsky]

Michael Shigorin пишет:

>On Fri, Jun 17, 2005 at 03:36:53PM +0400, Denis Smirnov wrote:
>  
>
>  
>
>>А вот 50$ за коробку с дистрибутивом для меня раз в год много.
>>    
>>
>
>У тебя и так есть коробка, да и слить его тебе недолго.  Мне тоже.
>Не передёргивай. (даже если я тоже считаю, что эта коробка ни
>разу не оправдывает этих денег)
>  
>
Коробка за $50 давно превратилась в подарочное издание. Есть DVD-версия, 
можно и скачать.

Rgrds, Алексей

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Denis Smirnov]

On Fri, Jun 17, 2005 at 06:01:43PM +0400, Aleksey Novodvorsky wrote:

>>> А вот 50$ за коробку с дистрибутивом для меня раз в год много.
>> У тебя и так есть коробка, да и слить его тебе недолго.  Мне тоже.
>> Не передёргивай. (даже если я тоже считаю, что эта коробка ни
>> разу не оправдывает этих денег)
AN> Коробка за $50 давно превратилась в подарочное издание. Есть DVD-версия, 
AN> можно и скачать.

Собственно у меня с коробкой проблем нет -- вроде пока никто не отменял
раздачу коробок членам team. И интернет мне позволяет сейчас обновлять
сизиф чуть ли не ежедневно. Когда не позволял, спасибо хорошим людям,
всегда была возможность приехать в офис с ziv'ой.

Вопрос-то другой. DVD-версия _мне_ так же не нужна. Почти совсем. Как
только отладят процесс выпекания дистрибутивов из Сизифа перестанет быть
нужной совсем -- всё равно устареет через полгода.

Я совсем другое хотел сказать. Что 50$/месяц за _поддержку_ это дёшево,
очень дёшево. 50$/год за коробку -- очень дорого. Я понимаю, что могу
написать на org@ и заказать чудесненькую такую поддержку. Но у меня
кошелёк не такой уж и толстый, чтобы в одиночку покупать услугу такого
уровня. Вы же не станете рисковать, чтобы _сначала_ предоставить более
качественную поддержку некоей группы пакетов, а потом думать как её
продать.

Поэтому я и говорю о необходимости в едином ресурсе, где была бы
информация:

1. о том кто, какую и почём работу _готов сделать_
2. о том кто, какую и почём работу _готов приобрести_

Естественно речь идёт только о том, что прямо или косвенно улучшит
дистрибутив.

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

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

http://freesource.info

[devel] Re: P: разделение критичности проверок для base..contrib

[Michael Shigorin]

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

On Sat, Jun 18, 2005 at 05:20:21PM +0400, Denis Smirnov wrote:
> Вы же не станете рисковать, чтобы _сначала_ предоставить более
> качественную поддержку некоей группы пакетов, а потом думать
> как её продать.

Вообще-то качественная поддержка -- это следствие работы support@
и индивидуальных майнтейнеров.  Второе -- "всё в наших руках",
а про важность (и следствия отсутствия) первого я многим в
московском офисе плешь проел, да только без cornet@ это похоже
на пустую трату времени, поэтому занимаюсь реализацией на базе
EMT.

> Поэтому я и говорю о необходимости в едином ресурсе, где была
> бы информация:
> 1. о том кто, какую и почём работу _готов сделать_
> 2. о том кто, какую и почём работу _готов приобрести_

Давай сделаем страничку на freesource/AltLinux?  Это уже >0.

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

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Denis Smirnov]

On Wed, Jun 22, 2005 at 05:55:39PM +0300, Michael Shigorin wrote:

>> Вы же не станете рисковать, чтобы _сначала_ предоставить более
>> качественную поддержку некоей группы пакетов, а потом думать
>> как её продать.
MS> Вообще-то качественная поддержка -- это следствие работы support@
MS> и индивидуальных майнтейнеров. 

+QA и security team.

MS> Второе -- "всё в наших руках",
MS> а про важность (и следствия отсутствия) первого я многим в
MS> московском офисе плешь проел, да только без cornet@ это похоже
MS> на пустую трату времени, поэтому занимаюсь реализацией на базе
MS> EMT.

Можно поинтересоваться в какой форме это реализуется в EMT?

>> Поэтому я и говорю о необходимости в едином ресурсе, где была
>> бы информация:
>> 1. о том кто, какую и почём работу _готов сделать_
>> 2. о том кто, какую и почём работу _готов приобрести_
MS> Давай сделаем страничку на freesource/AltLinux?  Это уже >0.

Легко. Если объём будет большой, то можно и отдельный движок для этого
всегда написать. Сейчас главная проблема в:

1. наличии этой информации
2. ссылка на эту страничку много где должна висеть
3. не уверен что эта страница должна быть r/w для _всех_.

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

http://freesource.info

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Alexey Rusakov]

On 22.06.2005 19:07, Denis Smirnov wrote:
>>>Поэтому я и говорю о необходимости в едином ресурсе, где была
>>>бы информация:
>>>1. о том кто, какую и почём работу _готов сделать_
>>>2. о том кто, какую и почём работу _готов приобрести_
>>>      
>MS> Давай сделаем страничку на freesource/AltLinux?  Это уже >0.
>
>Легко. Если объём будет большой, то можно и отдельный движок для этого
>всегда написать.
А нет ли уже существующего движка, который можно допилить для наших целей?

> Сейчас главная проблема в:
>
>1. наличии этой информации
>  
? По-моему, уже несколько человек вынашивают идею кому-нибудь дать 
денег, чтобы тот что-нибудь им сделал.

>2. ссылка на эту страничку много где должна висеть
>  
Для начала она должна висеть на фронтпейдже sisyphus.ru, имхо.

>3. не уверен что эта страница должна быть r/w для _всех_.
Проблема в том, что вики не очень подходит для таких вещей.

-- 
  Alexey "Ktirf" Rusakov

[devel] Re: P: разделение критичности проверок для base..contrib

[Michael Shigorin]

On Wed, Jun 22, 2005 at 07:07:47PM +0400, Denis Smirnov wrote:
> MS> а про важность (и следствия отсутствия) первого я многим в
> MS> московском офисе плешь проел, да только без cornet@ это похоже
> MS> на пустую трату времени, поэтому занимаюсь реализацией на базе
> MS> EMT.
> Можно поинтересоваться в какой форме это реализуется в EMT?

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

Вторая кучка -- вещи вроде monit, которые, похоже, будут
изыматься по причине заброшенности у текущих майнтейнеров
(с их [молчаливого] согласия).

> 2. ссылка на эту страничку много где должна висеть

Куда дотянусь -- там можно.  Хотя по-хорошему -- есть такая буква 
"ссылки" на сайте проекта и есть "карта сайта".

On Wed, Jun 22, 2005 at 08:19:45PM +0400, Alexey Rusakov wrote:
> >>>1. о том кто, какую и почём работу _готов сделать_
> >>>2. о том кто, какую и почём работу _готов приобрести_
> >MS> Давай сделаем страничку на freesource/AltLinux?  Это уже >0.
> >Легко. Если объём будет большой, то можно и отдельный движок
> >для этого всегда написать.
> А нет ли уже существующего движка, который можно допилить для
> наших целей?

Видел применение с такой целью форума (lafox.net/support) и
новостного движка (linux.kiev.ua/job.html).  Не фонтан, но
работает.  IMHO для старта может хватить и wiki, если кто-то
будет за этим присматривать -- а дальше жизнь покажет, насколько
оно реально востребовано и стоит мороки.

> >2. ссылка на эту страничку много где должна висеть
> Для начала она должна висеть на фронтпейдже sisyphus.ru, имхо.

Не вопрос.

> >3. не уверен что эта страница должна быть r/w для _всех_.
> Проблема в том, что вики не очень подходит для таких вещей.

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

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

[devel] Re: P: разделение критичности проверок для base..contrib

[Denis Smirnov]

Michael Shigorin wrote:

>>MS> а про важность (и следствия отсутствия) первого я многим в
>>MS> московском офисе плешь проел, да только без cornet@ это похоже
>>MS> на пустую трату времени, поэтому занимаюсь реализацией на базе
>>MS> EMT.
>>Можно поинтересоваться в какой форме это реализуется в EMT?
>>    
>>
>В такой, что ряд пакетов, которые в сизифе не устраивают, форкнут 
>и допиливается отдельно.  По мере получения удовлетворительных
>результатов на проектах, где это всё варится, будет мержиться.
>
>Вторая кучка -- вещи вроде monit, которые, похоже, будут
>изыматься по причине заброшенности у текущих майнтейнеров
>(с их [молчаливого] согласия).
>  
>
Ясно.

>>2. ссылка на эту страничку много где должна висеть
>>    
>>
>Куда дотянусь -- там можно.  Хотя по-хорошему -- есть такая буква 
>"ссылки" на сайте проекта и есть "карта сайта".
>  
>
Понял.

>>>>>1. о том кто, какую и почём работу _готов сделать_
>>>>>2. о том кто, какую и почём работу _готов приобрести_
>>>>>          
>>>>>
>>>MS> Давай сделаем страничку на freesource/AltLinux?  Это уже >0.
>>>Легко. Если объём будет большой, то можно и отдельный движок
>>>для этого всегда написать.
>>>      
>>>
>>А нет ли уже существующего движка, который можно допилить для
>>наших целей?
>>    
>>
>Видел применение с такой целью форума (lafox.net/support) и
>новостного движка (linux.kiev.ua/job.html).  Не фонтан, но
>работает.  IMHO для старта может хватить и wiki, если кто-то
>будет за этим присматривать -- а дальше жизнь покажет, насколько
>оно реально востребовано и стоит мороки.
>  
>
Тут не важно на чём сделано. Был бы контент, код написать всегда легко, 
когда ясно ради чего.

>>>3. не уверен что эта страница должна быть r/w для _всех_.
>>>      
>>>
>>Проблема в том, что вики не очень подходит для таких вещей.
>>    
>>
>
>Да, но как-то подходит... разводить по каждому чиху отдельную
>технологию тоже зачихаешься.
>  
>
wiki хороша тем, что то для чего предназначена, получается чудесно. А то 
для чего не предназначена, сделать можно. И, что самое прекрасное, 
вкрутить что-то своё в неё элементарно. Причём так, что это будет для 
просматривающих прозрачно.

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Denis Smirnov]

On Wed, Jun 22, 2005 at 08:19:45PM +0400, Alexey Rusakov wrote:

AR> А нет ли уже существующего движка, который можно допилить для наших целей?

Допилить и wiki можно. Там новые странные вещи прикручиваются легко.

AR> ? По-моему, уже несколько человек вынашивают идею кому-нибудь дать 
AR> денег, чтобы тот что-нибудь им сделал.

Вот её и надо где-то в одном месте просто тупо выложить. В любой форме.

AR> Проблема в том, что вики не очень подходит для таких вещей.

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

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

http://freesource.info

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Vitaly Lipatov]

On Wednesday 22 June 2005 19:07, Denis Smirnov wrote:
> MS> Давай сделаем страничку на freesource/AltLinux?  Это уже
> >0.
>
> Легко. Если объём будет большой, то можно и отдельный движок
> для этого всегда написать. Сейчас главная проблема в:
>
> 1. наличии этой информации
Ну место выделить тоже хорошо... Можно будет и писать заявки. Чем 
мы хуже Google :)
> 2. ссылка на эту страничку много где должна висеть
Ну в рамках доступного Linux-сообщества уж можно осветить...
> 3. не уверен что эта страница должна быть r/w для _всех_.
Для начала - почему нет? К чему ограничивать то, к чему никто не 
рвётся?
Я не уверен, что это должно быть в /AltLinux (задачи могут быть и 
дистрибутивонезависимые).
Нечто подобное мы замышляем в /WINE.


-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX!

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Denis Smirnov]

Vitaly Lipatov wrote:

>>MS> Давай сделаем страничку на freesource/AltLinux?  Это уже
>>    
>>
>>>0.
>>>      
>>>
>>Легко. Если объём будет большой, то можно и отдельный движок
>>для этого всегда написать. Сейчас главная проблема в:
>>
>>1. наличии этой информации
>>    
>>
>Ну место выделить тоже хорошо... Можно будет и писать заявки. Чем 
>мы хуже Google :)
>  
>
Ты сейчас со структурой удачно играешься. Выбери любое место, какое 
понравится :)

>>2. ссылка на эту страничку много где должна висеть
>>    
>>
>Ну в рамках доступного Linux-сообщества уж можно осветить...
>  
>
>>3. не уверен что эта страница должна быть r/w для _всех_.
>>    
>>
>Для начала - почему нет? К чему ограничивать то, к чему никто не 
>рвётся?
>  
>
Для начала -- ясно. А потом не стоит просто потому, что страница с 
_персональными_ данными должна редактироваться персоной ими владеющими. 
А то какой-нибудь Вася Пупкин напишет что некто VitalyLipatov готов за 1 
цент в год софт писать, а потом придётся удивляться что это столько 
странных писем приходит. Но пока народу мало этих проблем не будет -- 
легко отследить.

>Я не уверен, что это должно быть в /AltLinux (задачи могут быть и 
>дистрибутивонезависимые).
>Нечто подобное мы замышляем в /WINE.
>  
>
Полностью согласен.

[devel] Re: P: разделение критичности проверок для base..contrib

[Denis Smirnov]

Michael Shigorin wrote:

>>Что ты предлагаешь? У нас есть две проблемы, известные решения
>>которых друг с другом конфликтуют:
>>1. Сизиф становится не просто крив, а ужасен. Год назад я
>>практически без страха делал dist-upgrade средь бела дня на
>>боевом сервере, даже зная что простой в несколько часов будет
>>стоить мне денег. 
>>    
>>
>Это не "у нас", а "у тебя".  Я знаю только одного действительного
>опытного, но при этом сорвиголову, который, не читая sisyphus@,
>так делает.  И сам не делаю давно.
>  
>
Миша, ты не хуже меня знаешь, откуда берутся дистрибутивы. И что 
неоднократно обругиваемая многими политика выпуска дистрибутива с 
опозданиями более чем на полгода от запланированого является _в том 
числе_ следствием кривизны содержимого Сизифа.

>Развивай стабильный выпуск в backports, порой вливая в сизиф --
>или у тебя масштаб фронта, где надо самое-самое последнее по
>объективным причинам, и есть полсистемы?
>  
>
У меня лично нет ни единого повода доверять backports больше чем 
содержимому Сизифа. И практика спокойно обновляться из Сизифа, глядя "ну 
и что мне там сейчас nagios обматерит", за исключением ядер, 
инитскриптов, glibc и openssh пока себя более-менее оправдывает. 
Естественно делаю я это отнюдь не каждый день, и внимательно 
просматривая каждый пакет, который собираюсь обновить.

>А рассказывать сказки про "год назад деревья были зеленей" --
>не надо, поскольку год назад что-то только что вышло и была
>окрестность точки стабилизации.  Периодически [sic] это бывает.
>Соответственно после следующего фриза будет где-то так же.
>И после очередной дебардакизации -- опять щепки.
>  
>
Щипки летят периодически, это нормально. Только лететь они могут сильно 
по-разному, это первое. А второе -- насколько мантейнеры таки думают, 
прежде чем выложить пакет в сизиф.

>>Уровень оттестированности становится все хуже и хуже. А для
>>меня лично качество сборок ALT Team было одним из важнейших
>>причин перехода на ALT.  Думаю я не один такой.
>>    
>>
>Для меня -- тоже.  И именно из-за того, что хочется получше,
>и пишу сейчас ровно то, что пишу.
>  
>
Понимаю.

>Только я ещё/уже не настолько ^Wбезбашенный, чтобы не разделять
>разработку и эксплуатацию.  Если кто-то верит в объединяемость 
>этих полюсов или так и делает -- он рано или поздно стукнется 
>в крепкие грабли и будет сидеть обиженным, в лучшем случае
>прекрасно зная, что сам дурак.
>
>Это данность.
>  
>
А это тут причём?

>>2. Мантейнеров надо мотивировать.
>>Если начинает зверствовать QA, то мантейнерам "не по кайфу".
>>    
>>
>Даже если не зверствовать (что может быть в фирме), а просто
>задалбывать.  Восприятие-то тоже бывает разным.
>  
>
Не надо задалбывать. Надо аккуратно развешивать баги. Напоминалки от 
багзиллы приходят не столь уж часто, чтобы реально задалбывать.

>>Но с одним маленьким ограничением -- мантейнерам сказал
>>"молчать!" (поставив соответствующую строчку, затыкающую
>>конкретную проверку в спеке), и робот заткнулся и больше не
>>трогает.
>>    
>>
>Да-да, и залить в сизиф расставлялку затычек. :-/
>Дурь это.  Законов, строгость которых компенсируется забиванием, 
>и так пруд пруди.
>  
>
Дело не в законах. У нас нет возможности _заставить_ мантейнера делать 
так, как хочет кто-то ещё. Любая такая попытка будет заканчиваться 
вежливым или не очень предложением направится куда-нибудь очень далеко.

Дело в том, что мантейнер может просто _не знать_ многих вещей. Цена 
роста проекта в том, что даже если средний уровень квалификации 
мантейнера остаётся на месте, или даже растёт, количество людей, которым 
до ldv@, например, дальше чем до луны пешком растёт. В этом нет ничего 
плохого или хорошего -- это просто факт, который надо учитывать, не все 
мы тут супер-пупер хакеры. Я сам часто делаю такие ошибки, глядя на 
которые волосы на голове шевелятся.

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

Если ошибка есть -- она должна быть выявлена, желательно полностью 
автоматически, и зафиксирована. И установка тэгов проде verify_elf 
всего-лишь переводится на русский как "знаю о граблях, не считаю их 
достойными траты моего времени".

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

>>3. Таки сделать единую систему для финансирования таких разовых
>>правок.  Грубо говоря, если тысяча пользователей скинутся по 1$
>>и скажут -- Миша, пожалуйста, приведи в порядок xmms (при том
>>что работы там, как ты говорил, не много) -- думаю это будет
>>достаточной мотивацией, не правда ли? 
>>    
>>
>Необязательно "1000 по $1", скорее "двое-трое скинутся
>напильниками и перепилят инитскрипты трёх десятков зависших
>пакетов после переезда на новую схему" и подобное.
>  
>
А это по сути не важно. Сделает кто-либо, или заплатит чтобы сделали. 
Главное что проблема общеизвестна, и позиция мантейнера общеизвестна. И 
если речь идёт о деньгах, то цена тоже известна.

>Опять же моя позиция -- за качество должны платить те, кто в нём
>нуждается.  И столько, на сколько их нужды тянут.
>  
>
Именно так.

>Соответственно фирмы, озабоченные качеством пакетной базы
>дистрибутивов, должны содержать QA-команды, которые должны 
>заниматься как поиском ошибок и разработкой инструментария для
>автоматизации этого, так и _исправлением_ ошибок и разработкой
>методик и инструментария для автоматизации и этого при
>возможности.
>
>С волонтерами работает подход "с нами и вот так -- удобнее".
>А не построить всех в шеренгу по полтора и бегом марш.
>  
>
Вот потому я и говорю, что пусть QA зверствут, если может -- хорошо 
знать об ошибках. Главное чтобы это зверство не мешало мантейнерам жить.

>>Даже если пакет _очень_ критичен для дистрибутива. Да и не
>>одиночки тоже не шибко -- сколько ты получаешь за поддержку
>>Apache?
>>    
>>
>На предыдущей работе apache, mod_php, MySQL и PostgreSQL и были
>тем, за работу чего я получал зряплату.  Плюс к тому, это
>критичный сервис для нескольких более общественных проектов.
>  
>
Конкретно за _мантейнерство_, или за то что решения с их использованием 
работали? Это ведь большая разница. Я ведь тоже кормлюсь во многом с той 
же группы пакетов. Но таки тут мы скорее конечные пользователи. Причём 
если два года назад при необходимости я взял бы напильник и стал бы 
патчить, патчить, патчить... То сейчас предпочту скинуться с кем-нибудь 
ещё, и заплатить более квалифицированому человеку чтобы он патчил.

>>Что-то не заметно чтобы он у тебя был на первых местах по
>>важности в плане поддержки, и чтобы ты в него вкладывал много
>>времени.
>>    
>>
>Открою страшную тайну -- самые любимые пакеты -- это те, которые
>вообще не потребляют времени.  Потому как в сводках с разборки
>Sisyphus они не фигурируют, в bugtraq@ не светятся, работают 
>и каши не просят. :-)
>  
>
Верю :)

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

>>Скажу ещё больше, я согласин с at@ в том, что _мне тоже_ лично
>>не нужен дистрибутив. Совсем-совсем не нужен. А более
>>стабильный сизиф нужен. И я даже платить за него готов.
>>    
>>
>
>Слушай, вспомни мои высказывания в последнем забеге на тему 
>"стабильного сизифа".  Хороший рабочий current -- да, наверное,
>неплохо.  Но вот думать о поддерживаемости его _я_ не собираюсь,
>поскольку упираться в то, что на данном конкретном тазу было на
>скору руку заморожено невесть что потому, что на тестовом после
>обновления взорвалось что-то критичное -- а тут дырка и надо бы
>что-то с этим сделать -- не собираюсь.
>  
>
Хочу напомнить, что ситуация с Мастером до твоего личного вмешательства 
была ничуть не лучше.

>Заведи где-нить какое-нить gentoo, поживи на этом, потом вернёмся 
>к обсуждению.
>  
>
Я так похож на самоубийцу? Или на мазохиста? :)

>BTW: есть мнение, что надо двигаться в сторону 18-месячного
>интервала меджу выпусками (осень/весна) того, что вообще
>рекомендуется для серверов.  А вот настольное -- действительно
>раз в полгода выпускать.
>  
>
Ну и таки сервера бывают сильно-сильно разные. Но это уже не в тему.
Есть универсальный дистрибутив -- он должен содержать в том числе 
серверные компоненты. И быть на приемлимом уровне по стабильности. 
Должен быть серверный дистрибутив (сейчас его нет). И там да, фриз может 
и должен быть несколько месяцев.

>>И если бы его стабильность была такова, что я мог бы на боевом
>>сервере поставить dist-upgrade в крон, уезжая на месяц в отпуск
>>без ноутбука, то сумма типа 100$/месяц показалась бы мне даже
>>смешной.
>>    
>>
>Перечитай то обсуждение, пожалуйста.  Здесь и сейчас его повторять
>бессмысленно.
>
>Всё, что я могу сказать по сути -- это "надо .incoming" -- на
>сейчас заблокировано проблемами в APT.  Решить их я не могу,
>оценить стоимость решения -- тоже.
>  
>
.incmoing это той же серии решение, что и предлагаемые at@ различные 
тесты пакетов на вшивость.

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

>>А вот 50$ за коробку с дистрибутивом для меня раз в год много.
>>    
>>
>У тебя и так есть коробка, да и слить его тебе недолго.  Мне тоже.
>Не передёргивай. (даже если я тоже считаю, что эта коробка ни
>разу не оправдывает этих денег)
>  
>
Я не передёргиваю, а напоминаю что заплатить за постоянную поддержку 
группы пакетов, например мне, адекватнее чем за коробку. А коробки у 
меня даже две -- одну я брату покупал в подарок.

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Ivan Fedorov]

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

Denis Smirnov пишет:

> Если ошибка есть -- она должна быть выявлена, желательно полностью
> автоматически, и зафиксирована. И установка тэгов проде verify_elf
> всего-лишь переводится на русский как "знаю о граблях, не считаю их
> достойными траты моего времени".
Есть еще вариант:
"Я эту софтиту переписывать не собираюсь, а по другому ей не помочь".
Это конечно входит в твое определение, но объем работы в таком случае
обычно позволяет вынести это отдельным случаем.

>> Открою страшную тайну -- самые любимые пакеты -- это те, которые
>> вообще не потребляют времени.  Потому как в сводках с разборки
>> Sisyphus они не фигурируют, в bugtraq@ не светятся, работают и каши не
>> просят. :-)
>>  
>>
> Верю :)
+1
>> BTW: есть мнение, что надо двигаться в сторону 18-месячного
>> интервала меджу выпусками (осень/весна) того, что вообще
>> рекомендуется для серверов.  А вот настольное -- действительно
>> раз в полгода выпускать.
>>  
>>
> Ну и таки сервера бывают сильно-сильно разные. Но это уже не в тему.
> Есть универсальный дистрибутив -- он должен содержать в том числе
> серверные компоненты. И быть на приемлимом уровне по стабильности.
> Должен быть серверный дистрибутив (сейчас его нет). И там да, фриз может
> и должен быть несколько месяцев.
+1


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

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Aleksey Novodvorsky]

Господа,
мы снова пошли по кругу, --- проблемы одни и те же, они давно 
сформулированы и нужно их решать, насмотря на все противоречия.
Все прошлые обсуждения показывают, что мы их не решим в рассылке, нужна 
личная встреча. Я предлагаю всем, кто сможет, приехать в Обнинск на 
конференцию, можно чуть раньше, -- для обсуждения и выработки 
предложений, которые дальше можно уже доработать и принять здесь. 
Особенно важно, чтобы на встрече team были не только москвичи.
LF также не годится для таких обсуждений.

Rgrds, Алексей
Denis Smirnov пишет:

>On Fri, Jun 17, 2005 at 01:25:20PM +0300, Michael Shigorin wrote:
>
>  
>
>>>>Бишь баланс между силами и средствами на поиске и исправлении
>>>>проблем -- важнее.
>>>>        
>>>>
>>>Бесспорно. Впорос лишь где он проходит.
>>>      
>>>
>MS> Не знаю.  Но боюсь, что дальнейший сдвиг в сторону поиска и при
>MS> этом демотивации майнтейнеров может ненароком перешагнуть ещё
>MS> одну ступеньку.
>
>Что ты предлагаешь? У нас есть две проблемы, известные решения которых
>друг с другом конфликтуют:
>
>1. Сизиф становится не просто крив, а ужасен. Год назад я практически без
>страха делал dist-upgrade средь бела дня на боевом сервере, даже зная что
>простой в несколько часов будет стоить мне денег. 
>
>Сейчас я боюсь делать dist-upgrade. Единственное где я его делаю ежедневно
>-- мой ноутбук. И иногда при этом поминаю мантейнеров отдельных пакетов не
>самыми тёплыми словами, и мне это не нравится.
>
>Уровень оттестированности становится все хуже и хуже. А для меня лично
>качество сборок ALT Team было одним из важнейших причин перехода на ALT.
>Думаю я не один такой.
>
>2. Мантейнеров надо мотивировать.
>
>Если начинает зверствовать QA, то мантейнерам "не по кайфу". Если не
>зверствовать, пользователям проще будет перейти на Debian (они вроде
>начинают более вменяемую политику релизов пытаться проводить).
>
>Пока я вижу такое решение:
>
>1. QA должен не просто зверствовать, а таки зверствовать как истинные
>маньяки. Но с одним маленьким ограничением -- мантейнерам сказал
>"молчать!" (поставив соответствующую строчку, затыкающую конкретную
>проверку в спеке), и робот заткнулся и больше не трогает.
>
>2. Другой робот собирает информацию о подобных "кривых" пакетах --
>заинтересованые смогут прислать мантейнеру патчик.
>
>3. Таки сделать единую систему для финансирования таких разовых правок.
>Грубо говоря, если тысяча пользователей скинутся по 1$ и скажут -- Миша,
>пожалуйста, приведи в порядок xmms (при том что работы там, как ты
>говорил, не много) -- думаю это будет достаточной мотивацией, не правда
>ли? 
>
>В дополнение -- у нас есть серьёзная проблема. Sisyphus это проект _Team_,
>но возможностью финансировать разработчиков компонент обладают только
>несколько организаций. Мантейнеры-одиночки в принципе не могут кормиться
>со своей мантейнерской работы. Даже если пакет _очень_ критичен для
>дистрибутива. Да и не одиночки тоже не шибко -- сколько ты получаешь за
>поддержку Apache? Что-то не заметно чтобы он у тебя был на первых местах
>по важности в плане поддержки, и чтобы ты в него вкладывал много времени.
>А ведь это одна из ключевых компонент дистрибутива. И ведь желающих у
>тебя этот пакет позаимствовать почему-то не видно :)
>
>Скажу ещё больше, я согласин с at@ в том, что _мне тоже_ лично не нужен
>дистрибутив. Совсем-совсем не нужен. А более стабильный сизиф нужен. И я
>даже платить за него готов. И если бы его стабильность была такова, что я
>мог бы на боевом сервере поставить dist-upgrade в крон, уезжая на месяц в
>отпуск без ноутбука, то сумма типа 100$/месяц показалась бы мне даже
>смешной. А вот 50$ за коробку с дистрибутивом для меня раз в год много.
>В том числе и потому, что меня не устраивает качество этой коробки (общее
>_эмоциональное_ впечатление от 2.4 гораздо хуже чем от 2.2).
>
>  
>

[devel] Re: P: разделение критичности проверок для base..contrib

[Michael Shigorin]

On Fri, Jun 17, 2005 at 05:51:01PM +0400, Aleksey Novodvorsky wrote:
> мы снова пошли по кругу, --- проблемы одни и те же, они давно 
> сформулированы и нужно их решать, насмотря на все противоречия.

Да, конечно.  Ясно достаточно, чтобы было чего делать,
а не обсуждать.

[правильно]

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

[devel] Re: P: разделение критичности проверок для base..contrib

[Alexey Tourbin]

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

On Fri, Jun 17, 2005 at 05:51:01PM +0400, Aleksey Novodvorsky wrote:
> мы снова пошли по кругу, --- проблемы одни и те же, они давно 
> сформулированы и нужно их решать, насмотря на все противоречия.
> Все прошлые обсуждения показывают, что мы их не решим в рассылке, нужна 
> личная встреча. Я предлагаю всем, кто сможет, приехать в Обнинск на 
> конференцию, можно чуть раньше, -- для обсуждения и выработки 
> предложений, которые дальше можно уже доработать и принять здесь. 
> Особенно важно, чтобы на встрече team были не только москвичи.

Ищу спонсора.  Цена вопроса $200.  Интим не предлагать!
(Пациент стучит ложкой.)

Предлагаю закручивать гайки!  Если будем закручивать гайки, то будем
ловить ошибки; но будут также и недовольные пациенты, у которых не
собираются пакеты и приходит спам.  Есть и терпаевтические методы
воздействия на пациентов -- развешивать баги в багзиллу, но это не
обязывает к исполнению.

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Anton Farygin]

Alexey Tourbin wrote:

>On Fri, Jun 17, 2005 at 05:51:01PM +0400, Aleksey Novodvorsky wrote:
>  
>
>>мы снова пошли по кругу, --- проблемы одни и те же, они давно 
>>сформулированы и нужно их решать, насмотря на все противоречия.
>>Все прошлые обсуждения показывают, что мы их не решим в рассылке, нужна 
>>личная встреча. Я предлагаю всем, кто сможет, приехать в Обнинск на 
>>конференцию, можно чуть раньше, -- для обсуждения и выработки 
>>предложений, которые дальше можно уже доработать и принять здесь. 
>>Особенно важно, чтобы на встрече team были не только москвичи.
>>    
>>
>
>Ищу спонсора.  Цена вопроса $200.  Интим не предлагать!
>(Пациент стучит ложкой.)
>
>Предлагаю закручивать гайки!  Если будем закручивать гайки, то будем
>ловить ошибки; но будут также и недовольные пациенты, у которых не
>собираются пакеты и приходит спам.  Есть и терпаевтические методы
>воздействия на пациентов -- развешивать баги в багзиллу, но это не
>обязывает к исполнению.
>  
>
А я предлагаю начать с того, что бы усложнить тесты для прохода в Team 
новых мантейнеров.

Предлагаю давать тесты на сборку в пакеты в виде:
1) заведомо не собирающихся приложений, написанных на C (ведь правда, 
что каждый мантейнер должен хотя бы уметь читать код на C?)
2) в тестах должны быть: 1) библиотеки 2) системные сервисы 3) ...
4) желательно что бы собираемое приложение еще не было никем и никогда 
ранее собрано

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

можно так же в качестве тестов давать задание на сборку новых версий 
особенно страшных пакетов (аля GCC или rpm).

Rgds,
Rider

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Denis Smirnov]

On Mon, Jun 20, 2005 at 11:21:53AM +0400, Anton Farygin wrote:

AF> можно так же в качестве тестов давать задание на сборку новых версий 
AF> особенно страшных пакетов (аля GCC или rpm).

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

Hint: когда я собирал свои первые пакеты я был мягко скажем никаким
мантейнером. Но и пакеты были мягко скажем не шибко критичные.

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

http://freesource.info

Re: [devel] Re: P: разделение критичности проверок для base..contrib

[Dmitry V. Levin]

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

On Mon, Jun 20, 2005 at 11:21:53AM +0400, Anton Farygin wrote:
> А я предлагаю начать с того, что бы усложнить тесты для прохода в Team 
> новых мантейнеров.

:)

Мне кажется, что это не решит проблемы.  Лучше будет более чётко
формулировать требования и более просто выявлять их нарушения.

> Предлагаю давать тесты на сборку в пакеты в виде:
> 1) заведомо не собирающихся приложений, написанных на C (ведь правда, 
> что каждый мантейнер должен хотя бы уметь читать код на C?)
> 2) в тестах должны быть: 1) библиотеки 2) системные сервисы 3) ...
> 4) желательно что бы собираемое приложение еще не было никем и никогда 
> ранее собрано
> 
> т.е. - тесты на изучение кандидатом в мантейнеры специфики Sisyphus 
> должны быть как минимум такие, что бы нового мантейнера кунуть по полной 
> в проблемы, которые возникают при сборке кривых пакетов.
> 
> можно так же в качестве тестов давать задание на сборку новых версий 
> особенно страшных пакетов (аля GCC или rpm).

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


-- 
ldv

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

[devel] Re: P: разделение критичности проверок для base..contrib

[Michael Shigorin]

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

On Mon, Jun 20, 2005 at 11:21:53AM +0400, Anton Farygin wrote:
> А я предлагаю начать с того, что бы усложнить тесты для прохода
> в Team новых мантейнеров.

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

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

> Предлагаю давать тесты на сборку в пакеты в виде:
> 1) заведомо не собирающихся приложений, написанных на C (ведь правда, 
> что каждый мантейнер должен хотя бы уметь читать код на C?)
> 2) в тестах должны быть: 1) библиотеки 2) системные сервисы 3) ...
> 4) желательно что бы собираемое приложение еще не было никем и никогда 
> ранее собрано

-- нафиг не надо.

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

Если будет такое устрожение -- давайте сделаем devel-newbies@, 
думаю, мы с lav@ и несколькими ещё сможем курировать такую
команду.

PS: отдельно отмечу, что язык Це -- вовсе не священный и далеко
не настолько осмысленный, чтобы быть PreReq: майнтейнеру en masse.

PPS: easy :-)

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

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

Re: [devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs) JT про языки.

[Вячеслав Диконов]

В Птн, 17/06/2005 в 00:30 +0400, Alexey Tourbin пишет:
> On Thu, Jun 16, 2005 at 07:36:24PM +0300, Michael Shigorin wrote:
> С языком как раз плохо.  Население ex-USSR -- это примерно 200 млн.
> человек, население планеты -- примерно 6 млрд.  То, что мы тут пишем,
> в состоянии понять только 3% населения планеты, вернее, примерно такой
> же процент потенциально заинтересованных разработчиков.
Английский даст примерно 13% населения планеты, и заметно более высокий
процент программистов (наверное за счет вечно ругаемой нашими
программистами Индии :) ).

Кроме того, русский распространен и за пределами ex-СССP. С нашими
делегатами на разных международных попойках на слегка корявом русском
языке отлично общаются все соседние государства (вроде Чехии), и
некоторые совсем не соседние. Так что процент русского можно приподнять
до 5%.

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

Вероятно, что с течением времени нужно будет все писать на языке
описания смысла UNL (http://www.undl.org), из которого будет
автоматически делаться правильный текст на любом человеческом...

Re: [devel] RFC: test-libs

[Alexander Bokovoy]

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

On Thu, Jun 16, 2005 at 03:22:18AM +0400, Dmitry V. Levin wrote:
> > samba-common	/lib/libnss_wins.so	yperr_string
> Значит, libnss_wins нерабочий.
Это же не отдельная библиотека. Это подгружаемый модуль nss.
 
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

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

Re: [devel] RFC: test-libs

[Alexander Bokovoy]

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

On Fri, Jun 17, 2005 at 12:10:11AM +0400, Alexander Bokovoy wrote:
> On Thu, Jun 16, 2005 at 03:22:18AM +0400, Dmitry V. Levin wrote:
> > > samba-common	/lib/libnss_wins.so	yperr_string
> > Значит, libnss_wins нерабочий.
> Это же не отдельная библиотека. Это подгружаемый модуль nss.
Хотя в данном конкретном случае можно оторвать --with-automount и выкинуть
весь код поддержки NIS/NIS+, если он никому не нужен. 

Научить линковаться с libnsl в случае glibc и
HAVE_NETGROUP/WITH_AUTOMOUNT, наверное, тоже можно, но без того, что nidd
реализовал в сборочной среде Samba4 будет гораздо сложнее. Я подумаю на эту тему.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

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

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Fri, Jun 17, 2005 at 12:10:11AM +0400, Alexander Bokovoy wrote:
> On Thu, Jun 16, 2005 at 03:22:18AM +0400, Dmitry V. Levin wrote:
> > > samba-common	/lib/libnss_wins.so	yperr_string
> > Значит, libnss_wins нерабочий.
> Это же не отдельная библиотека. Это подгружаемый модуль nss.

А кто его подгружает?  libc?  Откуда уверенность, что в этом адресном
пространстве по случаю окажется libnsl, в котором yperr_string?

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

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Fri, Jun 17, 2005 at 12:58:05AM +0400, Alexey Tourbin wrote:
> > > > samba-common	/lib/libnss_wins.so	yperr_string
> > > Значит, libnss_wins нерабочий.
> > Это же не отдельная библиотека. Это подгружаемый модуль nss.
> А кто его подгружает?  libc?  Откуда уверенность, что в этом адресном
> пространстве по случаю окажется libnsl, в котором yperr_string?

Bug 82039 - dlopen() of /lib/libnss_wins.so fails
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82039

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

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Fri, Jun 17, 2005 at 01:00:41AM +0400, Alexey Tourbin wrote:
> On Fri, Jun 17, 2005 at 12:58:05AM +0400, Alexey Tourbin wrote:
> > > > > samba-common	/lib/libnss_wins.so	yperr_string
> > > > Значит, libnss_wins нерабочий.
> > > Это же не отдельная библиотека. Это подгружаемый модуль nss.
> > А кто его подгружает?  libc?  Откуда уверенность, что в этом адресном
> > пространстве по случаю окажется libnsl, в котором yperr_string?
> 
> Bug 82039 - dlopen() of /lib/libnss_wins.so fails
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82039

* Thu Feb 20 2003 Nalin Dahyabhai <nalin@redhat.com> 2.2.7a-4
- relink libnss_wins.so with SHLD="%{__cc} -lnsl" to force libnss_wins.so to
  link with libnsl, avoiding unresolved symbol errors on functions in libnsl

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

Re: [devel] Re: RFC: test-libs

[Alexander Bokovoy]

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

On Fri, Jun 17, 2005 at 01:03:22AM +0400, Alexey Tourbin wrote:
> On Fri, Jun 17, 2005 at 01:00:41AM +0400, Alexey Tourbin wrote:
> > On Fri, Jun 17, 2005 at 12:58:05AM +0400, Alexey Tourbin wrote:
> > > > > > samba-common	/lib/libnss_wins.so	yperr_string
> > > > > Значит, libnss_wins нерабочий.
> > > > Это же не отдельная библиотека. Это подгружаемый модуль nss.
> > > А кто его подгружает?  libc?  Откуда уверенность, что в этом адресном
> > > пространстве по случаю окажется libnsl, в котором yperr_string?
> > 
> > Bug 82039 - dlopen() of /lib/libnss_wins.so fails
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82039
> 
> * Thu Feb 20 2003 Nalin Dahyabhai <nalin@redhat.com> 2.2.7a-4
> - relink libnss_wins.so with SHLD="%{__cc} -lnsl" to force libnss_wins.so to
>   link with libnsl, avoiding unresolved symbol errors on functions in libnsl
Этого больше нет в Fedora Core 4. Они "сломаны", как и мы -- по умолчанию
в /etc/nsswitch.conf находится 'nis', который и грузит libnsl.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

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

Re: [devel] Re: RFC: test-libs

[Alexander Bokovoy]

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

On Fri, Jun 17, 2005 at 01:00:41AM +0400, Alexey Tourbin wrote:
> On Fri, Jun 17, 2005 at 12:58:05AM +0400, Alexey Tourbin wrote:
> > > > > samba-common	/lib/libnss_wins.so	yperr_string
> > > > Значит, libnss_wins нерабочий.
> > > Это же не отдельная библиотека. Это подгружаемый модуль nss.
> > А кто его подгружает?  libc?  Откуда уверенность, что в этом адресном
> > пространстве по случаю окажется libnsl, в котором yperr_string?
Конфигурация по умолчанию nsswitch.conf содержит nis, так что подгружается
она точно по умолчанию во все приложения.
 
> Bug 82039 - dlopen() of /lib/libnss_wins.so fails
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82039
Типичный RH-подход -- свои исправления не передавать в upstream и не
обсуждать эту проблему с upstream пакетов, которые RH не считает для себя
критическими. Кстати, в Fedora Core 4 оно также сломано, как и у нас --
сейчас проверил.

Вообще, при использовании --with-automount по идее должна libnsl
подхватываться и линковаться -- на Solaris 9/10 это как раз и происходит.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

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

Re: [devel] to nis or not to nis

[Dmitry V. Levin]

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

On Fri, Jun 17, 2005 at 01:30:34AM +0400, Alexander Bokovoy wrote:
> On Fri, Jun 17, 2005 at 01:00:41AM +0400, Alexey Tourbin wrote:
> > On Fri, Jun 17, 2005 at 12:58:05AM +0400, Alexey Tourbin wrote:
> > > > > > samba-common	/lib/libnss_wins.so	yperr_string
> > > > > Значит, libnss_wins нерабочий.
> > > > Это же не отдельная библиотека. Это подгружаемый модуль nss.
> > > А кто его подгружает?  libc?  Откуда уверенность, что в этом адресном
> > > пространстве по случаю окажется libnsl, в котором yperr_string?
> Конфигурация по умолчанию nsswitch.conf содержит nis, так что подгружается
> она точно по умолчанию во все приложения.

Это дело недолгого времени, я думаю.


-- 
ldv

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

Re: [devel] to nis or not to nis

[Alexander Bokovoy]

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

On Fri, Jun 17, 2005 at 02:08:04PM +0400, Dmitry V. Levin wrote:
> > > > А кто его подгружает?  libc?  Откуда уверенность, что в этом адресном
> > > > пространстве по случаю окажется libnsl, в котором yperr_string?
> > Конфигурация по умолчанию nsswitch.conf содержит nis, так что подгружается
> > она точно по умолчанию во все приложения.
> 
> Это дело недолгого времени, я думаю.
Будем совсем убивать NIS?

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

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

Re: [devel] to nis or not to nis

[Sergey Bolshakov]

>>>>> "Alexander" == Alexander Bokovoy <ab@altlinux.org> writes:

 > On Fri, Jun 17, 2005 at 02:08:04PM +0400, Dmitry V. Levin wrote:
 >> > > > А кто его подгружает?  libc?  Откуда уверенность, что в этом адресном
 >> > > > пространстве по случаю окажется libnsl, в котором yperr_string?
 >> > Конфигурация по умолчанию nsswitch.conf содержит nis, так что подгружается
 >> > она точно по умолчанию во все приложения.
 >> 
 >> Это дело недолгого времени, я думаю.
 > Будем совсем убивать NIS?

По факту он уже совсем убит, и как-то не жалко.

-- 

Re: [devel] to nis or not to nis

[Vitaly Lipatov]

On Friday 17 June 2005 17:10, Sergey Bolshakov wrote:
>  > Будем совсем убивать NIS?
>
> По факту он уже совсем убит, и как-то не жалко.
Не забудьте озвучить альтернативы.
Пожалуйста.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX!

Re: [devel] to nis or not to nis

[Ivan Fedorov]

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

Vitaly Lipatov пишет:
> On Friday 17 June 2005 17:10, Sergey Bolshakov wrote:
> 
>> > Будем совсем убивать NIS?
>>
>>По факту он уже совсем убит, и как-то не жалко.
> 
> Не забудьте озвучить альтернативы.
> Пожалуйста.
> 
LDAP


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

[devel] ldap roadmap (was: to nis or not to nis)

[Michael Shigorin]

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

On Sat, Jun 18, 2005 at 11:42:49AM +0900, Ivan Fedorov wrote:
> >> > Будем совсем убивать NIS?
> >>По факту он уже совсем убит, и как-то не жалко.
> > Не забудьте озвучить альтернативы.  Пожалуйста.
> LDAP

Угу.  У нас намечено:

- посмотреть RH/Fedora Directory Server;
- реализовать control'ируемую настройку аутентификации (pam),
  как ab@ с Женей Остапцом с год назад обсуждали.

Второе уже в процессе, обсуждение (пока) -- скорее в openldap@.

PS: кажется, Женя уже попал на OpenLDAP Team. :)

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

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

Re: [devel] ldap roadmap (was: to nis or not to nis)

[Alexander Bokovoy]

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

On Wed, Jun 22, 2005 at 05:45:36PM +0300, Michael Shigorin wrote:
> On Sat, Jun 18, 2005 at 11:42:49AM +0900, Ivan Fedorov wrote:
> > >> > Будем совсем убивать NIS?
> > >>По факту он уже совсем убит, и как-то не жалко.
> > > Не забудьте озвучить альтернативы.  Пожалуйста.
> > LDAP
> 
> Угу.  У нас намечено:
> 
> - посмотреть RH/Fedora Directory Server;
Забудь пока про RHDS. Как минимум до февраля 2006.


-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

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

Re: [devel] ldap roadmap

[Ivan Fedorov]

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

Alexander Bokovoy пишет:

>>>LDAP
>>
>>Угу.  У нас намечено:
>>
>>- посмотреть RH/Fedora Directory Server;
> 
> Забудь пока про RHDS. Как минимум до февраля 2006.

А что с ним не так?..


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

Re: [devel] ldap roadmap

[Alexander Bokovoy]

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

On Thu, Jun 23, 2005 at 11:50:00AM +0900, Ivan Fedorov wrote:
> >>Угу.  У нас намечено:
> >>
> >>- посмотреть RH/Fedora Directory Server;
> > 
> > Забудь пока про RHDS. Как минимум до февраля 2006.
> А что с ним не так?..
А он есть? Объявлено о предстоящем его выпуске и можно скачать триальную
версию. Часть кода пока не открыта, ряд плагинов и не будет открыт. В
реальной жизни эксплуатировать его пока рано, я бы подождал, пока RH его
выпустит хотя бы в рамках Fedora полноценно.

 Source Packages

 Check out our Build page to find out how to build from source.

 Note that this src.rpm is largely useless because it doesn't include all
 of the components required to build it. It's here for inspection purposes
 only. You're better off trying to build from source. 
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

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

[devel] [JT] Re: ldap roadmap

[Michael Shigorin]

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

On Thu, Jun 23, 2005 at 03:53:43PM +0400, Alexander Bokovoy wrote:
> > >>- посмотреть RH/Fedora Directory Server;
> > > Забудь пока про RHDS. Как минимум до февраля 2006.
> > А что с ним не так?..
> А он есть?

"Посмотрено" [x]

Спасибо, Саш.

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

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

Re: [devel] to nis or not to nis

[Вячеслав Диконов]

В Птн, 17/06/2005 в 14:21 +0400, Alexander Bokovoy пишет:
> Будем совсем убивать NIS?
А как, кстати, следует делать перемещаемые профили пользователей в
крошечной 100% ALTLinux сети?

Re: [devel] to nis or not to nis

[Ivan Fedorov]

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

Вячеслав Диконов пишет:

>>Будем совсем убивать NIS?
> 
> А как, кстати, следует делать перемещаемые профили пользователей в
> крошечной 100% ALTLinux сети?
> 
NFS, CIFS, GFS.


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

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 03:22:18AM +0400, Dmitry V. Levin wrote:
> > glibc-core	/lib/libthread_db-1.0.so	ps_pglobal_lookup
> Так и должно быть, эти символы живут в gdb.

А weak symbols здесь не помогут?

> > librpm	/usr/lib/librpmdb-4.0.4.so	hdrVec
> ldd -r не жалуется.  Бага в скрипте?

[at@basalt at]$ ldd -r /usr/lib/librpmdb-4.0.4.so
        libdb-4.3.so => /lib/libdb-4.3.so (0x0012c000)
        librpmio-4.0.4.so => /usr/lib/librpmio-4.0.4.so (0x00211000)
        libc.so.6 => /lib/i686/libc.so.6 (0x00234000)
        libbeecrypt.so.2 => /usr/lib/libbeecrypt.so.2 (0x00357000)
        libbz2.so.1 => /lib/libbz2.so.1 (0x00370000)
        libz.so.1 => /lib/libz.so.1 (0x00382000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
        librt.so.1 => /lib/i686/librt.so.1 (0x00395000)
        libpthread.so.0 => /lib/i686/libpthread.so.0 (0x003a7000)
undefined symbol: hdrVec        (/usr/lib/librpmdb-4.0.4.so)
undefined symbol: _noDirTokens  (/usr/lib/librpmdb-4.0.4.so)
undefined symbol: tagValue      (/usr/lib/librpmdb-4.0.4.so)
undefined symbol: compressFilelist      (/usr/lib/librpmdb-4.0.4.so)
undefined symbol: expandFilelist        (/usr/lib/librpmdb-4.0.4.so)
undefined symbol: tagName       (/usr/lib/librpmdb-4.0.4.so)
undefined symbol: headerNVR     (/usr/lib/librpmdb-4.0.4.so)
undefined symbol: providePackageNVR     (/usr/lib/librpmdb-4.0.4.so)
[at@basalt at]$

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

Re: [devel] RFC: test-libs

[Sergey V Turchin]

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

В сообщении от Четверг 16 Июнь 2005 02:37 Alexey Tourbin написал(a):
> Здравствуйте.
>
> Суть вопроса в следующем: разделяемые библиотеки (по крайней мере
> те из них, которые находятся в публичных местах) не должны
> содержать undefined symbols.  Такие библиотеки как бы "замкнуты".
>  Это дает возможность "свободно" с ними линковаться.  В этом одно
> из преимуществ разделяемых библиотек: для правильной линковки с
> ними, по идее, не требуется никакой внешней мета-информации
> (навроде *.la файлов).
Для kde-шных требуются, но это захачено.
Могу вернуть *.la файлы ;-)

[...]

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 01:18:47PM +0400, Sergey V Turchin wrote:
> В сообщении от Четверг 16 Июнь 2005 02:37 Alexey Tourbin написал(a):
> > Здравствуйте.
> >
> > Суть вопроса в следующем: разделяемые библиотеки (по крайней мере
> > те из них, которые находятся в публичных местах) не должны
> > содержать undefined symbols.  Такие библиотеки как бы "замкнуты".
> >  Это дает возможность "свободно" с ними линковаться.  В этом одно
> > из преимуществ разделяемых библиотек: для правильной линковки с
> > ними, по идее, не требуется никакой внешней мета-информации
> > (навроде *.la файлов).
> Для kde-шных требуются, но это захачено.

*Не должно* требоваться при обычной линковке `gcc -l%name'.  В этом
смысл RFC.  (RFC -- инициативное предложение, которое обсуждается и может
быть адаптировано в качестве полиси.)

> Могу вернуть *.la файлы ;-)

Все *.la файлы вообще можно было бы вернуть, но исключительно из
соображений legacy (+ статической линковки, которая без *.la файлов,
кажется, идёт лесом).  Это не тривиально.

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

Re: [devel] Re: RFC: test-libs

[Sergey V Turchin]

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

В сообщении от Четверг 16 Июнь 2005 16:40 Alexey Tourbin написал(a):

[...]

> *Не должно* требоваться при обычной линковке `gcc -l%name'.  В
А это необычная линковка 'gcc'.
Я то без проблем повыключаю в .spec, а у других начнут патчи 
появляться, как в amarok-1.2.4-alt1 (ни один не нужен).

> этом смысл RFC.  (RFC -- инициативное предложение, которое
> обсуждается и может быть адаптировано в качестве полиси.)
>
> > Могу вернуть *.la файлы ;-)
> Все *.la файлы вообще можно было бы вернуть, но исключительно из
> соображений legacy (+ статической линковки, которая без *.la
> файлов, кажется, идёт лесом).  Это не тривиально.
Можно удалять их перед сборкой и отключаемым сделать при помощи 
макроса.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] Re: RFC: test-libs

[Alexey I. Froloff]

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

* Sergey V Turchin <zerg@> [050616 17:36]:
> > > Могу вернуть *.la файлы ;-)
> > Все *.la файлы вообще можно было бы вернуть, но исключительно из
> > соображений legacy (+ статической линковки, которая без *.la
> > файлов, кажется, идёт лесом).  Это не тривиально.
> Можно удалять их перед сборкой и отключаемым сделать при помощи 
> макроса.
Ну, по большому счёту *.la файлы реально необходимы только при
статической линковке.  Следовательно место им в -devel-static.

-- 
Regards, Sir Raorn.
-------------------
Я прекрасно понимаю, что патч хороший.. но если сама его идея уже
морально устарела... зачем он нужен? ;-)
		-- rider in devel@

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

Re: [devel] Re: RFC: test-libs

[Sergey V Turchin]

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

В сообщении от Четверг 16 Июнь 2005 17:41 Alexey I. Froloff 
написал(a):

[...]

> Ну, по большому счёту *.la файлы реально необходимы только при
> статической линковке.
Нативному KDЮ для динамической нужны.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] Re: RFC: test-libs

[Alexey I. Froloff]

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

* Sergey V Turchin <zerg@> [050616 17:46]:
> > Ну, по большому счёту *.la файлы реально необходимы только при
> > статической линковке.
> Нативному KDЮ для динамической нужны.
Это половые трудности самого KDЯ.  Именно это я имел в виду под
"использованием GNU autotools не по назначению".

-- 
Regards, Sir Raorn.
-------------------
> Не так давно в Сизифе появидся этот модуль: python-module-twisted
Он там появился по ошибке.
		-- morozov in sisyphus@

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

Re: [devel] Re: RFC: test-libs

[Sergey V Turchin]

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

В сообщении от Четверг 16 Июнь 2005 17:48 Alexey I. Froloff 
написал(a):
> * Sergey V Turchin <zerg@> [050616 17:46]:
> > > Ну, по большому счёту *.la файлы реально необходимы только
> > > при статической линковке.
> >
> > Нативному KDЮ для динамической нужны.
>
> Это половые трудности самого KDЯ.
Само KDE их не испытывает. Их ощущаю я, например :-)

> Именно это я имел в виду под 
> "использованием GNU autotools не по назначению".
Давайте их испортим, чтоб невозможно было ;-)

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 05:41:54PM +0400, Alexey I. Froloff wrote:
> * Sergey V Turchin <zerg@> [050616 17:36]:
> > > > Могу вернуть *.la файлы ;-)
> > > Все *.la файлы вообще можно было бы вернуть, но исключительно из
> > > соображений legacy (+ статической линковки, которая без *.la
> > > файлов, кажется, идёт лесом).  Это не тривиально.
> > Можно удалять их перед сборкой и отключаемым сделать при помощи 
> > макроса.
> Ну, по большому счёту *.la файлы реально необходимы только при
> статической линковке.  Следовательно место им в -devel-static.

У статической линковки на платформе GNU/Linux (glibc) имеется Одна
Большая Проблема: сломанный резольвер.  См.
http://www.livejournal.com/users/avva/1380158.html?thread=26193470#t26193470

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

Re: [devel] Re: RFC: test-libs

[Dmitry V. Levin]

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

On Thu, Jun 16, 2005 at 07:11:40PM +0400, Alexey Tourbin wrote:
> On Thu, Jun 16, 2005 at 05:41:54PM +0400, Alexey I. Froloff wrote:
> > * Sergey V Turchin <zerg@> [050616 17:36]:
> > > > > Могу вернуть *.la файлы ;-)
> > > > Все *.la файлы вообще можно было бы вернуть, но исключительно из
> > > > соображений legacy (+ статической линковки, которая без *.la
> > > > файлов, кажется, идёт лесом).  Это не тривиально.
> > > Можно удалять их перед сборкой и отключаемым сделать при помощи 
> > > макроса.
> > Ну, по большому счёту *.la файлы реально необходимы только при
> > статической линковке.  Следовательно место им в -devel-static.
> 
> У статической линковки на платформе GNU/Linux (glibc) имеется Одна
> Большая Проблема: сломанный резольвер.  См.
> http://www.livejournal.com/users/avva/1380158.html?thread=26193470#t26193470

По этому адресу про resolver ничего не написано.
А то, что там написано, напоминает трёп бездельников.
Ну а в чём, собственно говоря, проблема?


-- 
ldv

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

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Thu, Jun 16, 2005 at 07:20:36PM +0400, Dmitry V. Levin wrote:
> > У статической линковки на платформе GNU/Linux (glibc) имеется Одна
> > Большая Проблема: сломанный резольвер.  См.
> > http://www.livejournal.com/users/avva/1380158.html?thread=26193470#t26193470
> 
> По этому адресу про resolver ничего не написано.
> А то, что там написано, напоминает трёп бездельников.
> Ну а в чём, собственно говоря, проблема?

$ cat test.c
#include <stdio.h>
#include <netdb.h>
int main()
{
        struct hostent *h = gethostbyname("localhost");
        printf("%s\n", h->h_name);
        return 0;
}
$ gcc -static test.c
/home/at/tmp/cceSSWrL.o(.text+0x25): In function `main':
test.c: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
$ filereq /dev/stdout ./a.out
localhost.localdomain
/etc/host.conf
/etc/hosts
/etc/ld.so.cache
/etc/nsswitch.conf
/etc/resolv.conf
/lib/i686/ld-linux.so.2
/lib/libc.so.6
/lib/libnss_files.so.2
$

То есть статически слинкованный c libc.a бинарь всё равно/в любом случае
подгружает разделяемые библиотеки, даже включая libc.so.6!  Причем,
требуется та же самая версия разделяемых библиотек, совпадение soname'ов
недостаточно.  Теряется главное и практически единственное преимущество
статической линковки: независимость от окружающей среды и переносимость
между различными хост-системами; в чем, безусловно, имеется определённая
проблема.  За примерами далеко ходить не надо: после обновления glibc
статически собранный /bin/rpm стал валиться в корку.

Так вот, бездельники и спрашивают: что же это за система, в которой
нихрена статически собрать нельзя - резолвер работать не будет?!

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

Re: [devel] Re: RFC: test-libs

[Dmitry V. Levin]

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

On Thu, Jun 16, 2005 at 07:52:44PM +0400, Alexey Tourbin wrote:
> On Thu, Jun 16, 2005 at 07:20:36PM +0400, Dmitry V. Levin wrote:
> > > У статической линковки на платформе GNU/Linux (glibc) имеется Одна
> > > Большая Проблема: сломанный резольвер.  См.
[...]
> test.c: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
[...]
> То есть статически слинкованный c libc.a бинарь всё равно/в любом случае
> подгружает разделяемые библиотеки, даже включая libc.so.6!  Причем,
> требуется та же самая версия разделяемых библиотек, совпадение soname'ов
> недостаточно.  Теряется главное и практически единственное преимущество
> статической линковки: независимость от окружающей среды и переносимость
> между различными хост-системами; в чем, безусловно, имеется определённая
> проблема.  За примерами далеко ходить не надо: после обновления glibc
> статически собранный /bin/rpm стал валиться в корку.

Это не значит, что resolver сломан.

> Так вот, бездельники и спрашивают: что же это за система, в которой
> нихрена статически собрать нельзя - резолвер работать не будет?!

Собери его статически, положи, например, в libc_nonshared.a, и будет тебе
счастье.  Только мне такого счастья не надо.


-- 
ldv

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

[devel] glibc static resolver?

[Michael Shigorin]

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

On Thu, Jun 16, 2005 at 08:33:01PM +0400, Dmitry V. Levin wrote:
> > Так вот, бездельники и спрашивают: что же это за система, в
> > которой нихрена статически собрать нельзя - резолвер работать
> > не будет?!
> Собери его статически, положи, например, в libc_nonshared.a, и
> будет тебе счастье.  Только мне такого счастья не надо.

А это получается оформить каким-то glibc-resolver-static?
Типа, для тех, кто ССЗБ или отдаёт отчёт?

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

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

Re: [devel] RFC: test-libs

[Andrey Astafiev]

Alexey Tourbin wrote

> liba2ps	/usr/lib/liba2ps.so.1	program_name

program_name в данном случае -- имя внешней переменной.
Как можно это исправить? Значит ли это, что библиотека
не должна содержать объявлений типа extern char *program_name,
как в данном случае?


-- 
Andrey Astafiev
andrei (at) altlinux (d0t) ru

[devel] Re: RFC: test-libs

[Alexey Tourbin]

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

On Sun, Jun 19, 2005 at 04:56:00PM +0400, Andrey Astafiev wrote:
> > liba2ps	/usr/lib/liba2ps.so.1	program_name
> 
> program_name в данном случае -- имя внешней переменной.
> Как можно это исправить? Значит ли это, что библиотека
> не должна содержать объявлений типа extern char *program_name,
> как в данном случае?

Хм.  Получается, что библиотека линкуется с бинарём, а не бинарь --
с библиотекой.  extern объявления в библиотеке, конечно же, возможны,
но они, по идее, должны резольвиться в другие библиотеки, а не в бинари.

По поводу program_name, первое, что мне пришло в голову:

$ cat test.c
#include <stdio.h>
#include <stdlib.h>
int main()
{
        char *progname = getenv("_");
        if (!progname)
                return 1;
        printf("%s\n", progname);
        return 0;
}
$ gcc test.c
$ ./a.out
/home/at/./a.out
$

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

Re: [devel] Re: RFC: test-libs

[Dmitry V. Levin]

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

On Sun, Jun 19, 2005 at 05:49:54PM +0400, Alexey Tourbin wrote:
> On Sun, Jun 19, 2005 at 04:56:00PM +0400, Andrey Astafiev wrote:
> > > liba2ps	/usr/lib/liba2ps.so.1	program_name
> > 
> > program_name в данном случае -- имя внешней переменной.
> > Как можно это исправить? Значит ли это, что библиотека
> > не должна содержать объявлений типа extern char *program_name,
> > как в данном случае?
> 
> Хм.  Получается, что библиотека линкуется с бинарём, а не бинарь --
> с библиотекой.  extern объявления в библиотеке, конечно же, возможны,
> но они, по идее, должны резольвиться в другие библиотеки, а не в бинари.

Это очень плохой стиль.

А вместо program_name можно использовать program_invocation_name или
program_invocation_short_name, в зависимости от потребностей.

P.S.  Почему бы вам не поискать более простое средство чтения документации
по GNU Libc?


-- 
ldv

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