Repocop reports for by-leader @python

	rpm id	test	status	message
	fail2ban-0.11.2-alt4.noarch	init-condrestart	fail	/etc/rc.d/init.d/fail2ban: missing condstop target. ERROR: alt-specific script %_sbindir/preun_service (used in your %preun_service macro) depends on condstop. Please, fix.
	fail2ban-0.11.2-alt4.noarch	init-lsb	warn	/etc/rc.d/init.d/fail2ban: lsb init header missing. See http://www.altlinux.org/Services_Policy for details.
	fail2ban-0.11.2-alt4.noarch	subdir-in-var-run	info	Found a subdir in /var/run or /var/lock. /var/run and /var/lock may be mounted as temporary filesystems, so the init.d scripts must handle this correctly. This will typically amount to creating any required subdirectories dynamically when the init.d script is run, rather than including them in the package and relying on rpm to create them.
	mailman3-3.3.10-alt1.noarch	sisyphus_check	fail	sisyphus_check failed: /ALT/Sisyphus/files/noarch/RPMS/mailman3-3.3.10-alt1.noarch.rpm: Invalid path names: /usr/lib/tmpfiles.d/mailman3.conf sisyphus_check: check-fhs ERROR: FHS violation
	mailman3-3.3.10-alt1.noarch	subdir-in-var-run	info	Found a subdir in /var/run or /var/lock. /var/run and /var/lock may be mounted as temporary filesystems, so the init.d scripts must handle this correctly. This will typically amount to creating any required subdirectories dynamically when the init.d script is run, rather than including them in the package and relying on rpm to create them.
	mailman3-3.3.10-alt1.noarch	systemd-but-no-native-init	experimental	The package have native systemd file(s) but no SysV init scripts.
	python-module-egenix-mx-base-3.2.8-alt1.x86_64	arch-dep-package-has-big-usr-share	info	The package has a significant amount of architecture-independent data in /usr/share, while it is an architecture-dependent package. This is wasteful of mirror space and bandwidth, as we then end up with multiple copies of this data, one for each architecture. If the data in /usr/share is not architecture-independent, it is a policy violation, and in this case, you should move that data elsewhere.
	python3-module-dialog-3.4.0-alt2.noarch	unsafe-tmp-usage-in-scripts	info	The test discovered scripts with errors which may be used by a user for damaging important system files. For example if a script uses in its work a temp file which is created in /tmp directory, then every user can create symlinks with the same name (pattern) in this directory in order to destroy or rewrite some system or another user's files. Scripts _must_ _use_ mktemp/tempfile or must use $TMPDIR. mktemp/tempfile is safest. $TMPDIR is safer than /tmp/ because libpam-tmpdir creates a subdirectory of /tmp that is only accessible by that user, and then sets TMPDIR and other variables to that. Hence, it doesn't matter nearly as much if you create a non-random filename, because nobody but you can access it. Found error in /usr/share/doc/python3-module-dialog-3.4.0/examples/with-autowidgetsize/demo.py: $ grep /tmp/ /usr/share/doc/python3-module-dialog-3.4.0/examples/with-autowidgetsize/demo.py easily append data. With the {widget} widget, you can see the data stream \ flow in real time. To create a FIFO, you can use the commmand mkfifo(1), like this: % mkfifo /tmp/my_shiny_new_fifo Then, you can cat(1) data to the FIFO like this: % cat >>/tmp/my_shiny_new_fifo First line of text Second line of text ... You can end the input to cat(1) by typing Ctrl-D at the beginning of a \ Found error in /usr/share/doc/python3-module-dialog-3.4.0/examples/demo.py: $ grep /tmp/ /usr/share/doc/python3-module-dialog-3.4.0/examples/demo.py easily append data. With the {widget} widget, you can see the data stream \ flow in real time. To create a FIFO, you can use the commmand mkfifo(1), like this: % mkfifo /tmp/my_shiny_new_fifo Then, you can cat(1) data to the FIFO like this: % cat >>/tmp/my_shiny_new_fifo First line of text Second line of text ... You can end the input to cat(1) by typing Ctrl-D at the beginning of a \
	python3-module-facebook-sdk-1.0.0-alt2.noarch	rpm-filesystem-conflict-file-file	warn	There are file conflicts with the package python3-module-tornado-facebook-sdk-0.1.0-alt2.noarch, for example, /usr/lib/python3/site-packages/facebook/__init__.py (4 file conflicts in total). Moreover, the packages have no explicit conflicts with each other. You should add explicit conflicts, or, if conflicts are avoidable, consider using alternatives.
	python3-module-geventhttpclient-facebook-0.4.4-alt2.noarch	rpm-filesystem-conflict-file-file	warn	There are file conflicts with the package python3-module-requests-facebook-0.4.0-alt2.noarch, for example, /usr/lib/python3/site-packages/__pycache__/facebook.cpython-37.opt-1.pyc (4 file conflicts in total). Moreover, the packages have no explicit conflicts with each other. You should add explicit conflicts, or, if conflicts are avoidable, consider using alternatives.
	python3-module-requests-facebook-0.4.0-alt2.noarch	rpm-filesystem-conflict-file-file	warn	There are file conflicts with the package python3-module-geventhttpclient-facebook-0.4.4-alt2.noarch, for example, /usr/lib/python3/site-packages/__pycache__/facebook.cpython-37.opt-1.pyc (4 file conflicts in total). Moreover, the packages have no explicit conflicts with each other. You should add explicit conflicts, or, if conflicts are avoidable, consider using alternatives.
	python3-module-tornado-facebook-sdk-0.1.0-alt2.noarch	rpm-filesystem-conflict-file-file	warn	There are file conflicts with the package python3-module-facebook-sdk-1.0.0-alt2.noarch, for example, /usr/lib/python3/site-packages/facebook/__init__.py (4 file conflicts in total). Moreover, the packages have no explicit conflicts with each other. You should add explicit conflicts, or, if conflicts are avoidable, consider using alternatives.
	tuxpaint-0.9.34-alt1.x86_64	arch-dep-package-has-big-usr-share	info	The package has a significant amount of architecture-independent data in /usr/share, while it is an architecture-dependent package. This is wasteful of mirror space and bandwidth, as we then end up with multiple copies of this data, one for each architecture. If the data in /usr/share is not architecture-independent, it is a policy violation, and in this case, you should move that data elsewhere.
	tuxpaint-0.9.34-alt1.x86_64	iconsdir	experimental	Please, move pixmaps from /usr/share/pixmaps to %_liconsdir, %_niconsdir, %_miconsdir according to their size. See http://www.altlinux.org/IconPathsPolicy.