Comments

361 Comments
karma

Was this update ever tested? Mock poorly fails on RHEL 7.7 with SELinux errors when building a package:

type=AVC msg=audit(1565368068.535:11095): avc:  denied  { read } for  pid=46206 comm="groupadd" name="run" dev="dm-0" ino=800267 scontext=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mock_var_lib_t:s0 tclass=lnk_file permissive=0
type=SYSCALL msg=audit(1565368068.535:11095): arch=x86_64 syscall=connect success=no exit=EACCES a0=4 a1=7ffe52230040 a2=6e a3=40 items=0 ppid=46205 pid=46206 auid=3000051 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1118 comm=groupadd exe=/usr/sbin/groupadd subj=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1565368069.966:11119): avc:  denied  { write } for  pid=46244 comm="groupadd" path="/dev/null" dev="dm-0" ino=800206 scontext=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mock_var_lib_t:s0 tclass=chr_file permissive=0
type=AVC msg=audit(1565368069.966:11119): avc:  denied  { write } for  pid=46244 comm="groupadd" path="/dev/null" dev="dm-0" ino=800206 scontext=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mock_var_lib_t:s0 tclass=chr_file permissive=0
type=SYSCALL msg=audit(1565368069.966:11119): arch=x86_64 syscall=execve success=yes exit=0 a0=1a327b0 a1=1a2fd30 a2=1a31be0 a3=7ffda2580a60 items=0 ppid=46238 pid=46244 auid=3000051 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1118 comm=groupadd exe=/usr/sbin/groupadd subj=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1565368070.38:11132): avc:  denied  { write } for  pid=46260 comm="useradd" path="/dev/null" dev="dm-0" ino=800206 scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mock_var_lib_t:s0 tclass=chr_file permissive=0
type=AVC msg=audit(1565368070.38:11132): avc:  denied  { write } for  pid=46260 comm="useradd" path="/dev/null" dev="dm-0" ino=800206 scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mock_var_lib_t:s0 tclass=chr_file permissive=0
type=SYSCALL msg=audit(1565368070.38:11132): arch=x86_64 syscall=execve success=yes exit=0 a0=1a33270 a1=1a32d50 a2=1a31be0 a3=7ffda2580a60 items=0 ppid=46238 pid=46260 auid=3000051 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1118 comm=useradd exe=/usr/sbin/useradd subj=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1565368070.44:11133): avc:  denied  { read } for  pid=46260 comm="useradd" name="run" dev="dm-0" ino=800267 scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mock_var_lib_t:s0 tclass=lnk_file permissive=0
type=SYSCALL msg=audit(1565368070.44:11133): arch=x86_64 syscall=connect success=no exit=EACCES a0=5 a1=7ffd92b62af0 a2=6e a3=11 items=0 ppid=46238 pid=46260 auid=3000051 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1118 comm=useradd exe=/usr/sbin/useradd subj=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1565368096.180:11209): avc:  denied  { write } for  pid=46732 comm="groupadd" name="group" dev="dm-0" ino=806120 scontext=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(1565368096.180:11209): arch=x86_64 syscall=open success=no exit=EACCES a0=56463bb7f5a0 a1=20902 a2=0 a3=8 items=0 ppid=46730 pid=46732 auid=3000051 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1118 comm=groupadd exe=/usr/sbin/groupadd subj=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1565368103.576:11285): avc:  denied  { write } for  pid=46804 comm="restorecon" path="/dev/null" dev="dm-0" ino=800206 scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mock_var_lib_t:s0 tclass=chr_file permissive=0
type=AVC msg=audit(1565368103.576:11285): avc:  denied  { write } for  pid=46804 comm="restorecon" path="/dev/null" dev="dm-0" ino=800206 scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mock_var_lib_t:s0 tclass=chr_file permissive=0
type=SYSCALL msg=audit(1565368103.576:11285): arch=x86_64 syscall=execve success=yes exit=0 a0=f64170 a1=f63b10 a2=f63920 a3=7ffd776df720 items=0 ppid=46799 pid=46804 auid=3000051 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1118 comm=restorecon exe=/usr/sbin/setfiles subj=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 key=(null)

Downgrading mock-1.4.17-1.el7.noarch to mock-1.4.16-1.el7.noarch solves the issue, thus this is not a RHEL 7.7, but a mock issue.

LGTM :)

BZ#1738720 Please build python-easygui for EPEL 8
karma

From my point of view, the license tag does not match the actual license; https://src.fedoraproject.org/rpms/conspy/pull-request/1

User Icon robert commented & provided feedback on icu-63.2-1.fc30 5 years ago
karma

Seems to break qt5-qtwebengine based applications

LGTM :)

LGTM :)

karma

I am sorry, but libdvbv5-1.16.5-1.fc30 (previous update) and libdvbv5-1.16.5-2.fc30 (this update) are both just broken, they do not fix RHBZ #1695023 at all. The only working package is the old libdvbv5-1.16.3-2.fc30. Please unpush this broken update.

BZ#1695023 unable to open dvb device after update to 1.16.5

The problem is the error message in the initial comment (spewed by the default cron job) which renders the clamav-unofficial-sigs package quite useless by default on RHEL/CentOS 6, because clamd gets never notified (except for some whole system reboots) about any signature updates. This results from an obviously untested clamav-unofficial-sigs package update on RHEL/CentOS 6, given the issue exists reproducibly even with fresh clamav-unofficial-sigs installations, not just with updated clamav-unofficial-sigs installations. The conclusion are the fixes I submitted via pull requests.

Additionally: clamav-unofficial-sigs.spec contains:

%attr(0755,clamupdate,clamupdate) %dir %{_localstatedir}/lib/%{name}
%attr(0755,clamupdate,clamupdate) %dir %{_localstatedir}/log/%{name}

However a few lines above there is:

%pre
getent group clam-update >/dev/null || groupadd -r clam-update
getent passwd clam-update >/dev/null || \
    useradd -r -g clam-update -d %{_localstatedir}/lib/%{name} -s /bin/bash \
    -c "%{name} user account" clam-update
exit 0

It's actually hard to believe that this was tested, ever.

BZ#1683646 Please build latest clamav-unofficial-sigs for EPEL 6
/usr/sbin/clamav-unofficial-sigs.sh: line 1090: service: command not found

Kevin: That's interesting! Moving the content from /etc/incron.d/reproducer.conf to /var/spool/incron/root (via incrontab -e) seems indeed to solve this. No more zillions of incrond processes yet! May we get the same fix also for system wide /etc/incron.d/, please?

Important: The IN_NO_LOOP option still does no longer work, the example above creates endless loops with user incrontab (even it's overall better than before).

Kevin: Yes, quite reliable:

$ rpm -q incron
incron-0.5.12-9.el7.x86_64
$ for i in $(seq 1 250); do date > /var/www/html/${i}.txt; done
$ for i in $(seq 1 50); do mkdir -p /var/www/html/${i}; done
$ cat /etc/incron.d/reproducer.conf 
/var/www/html/ IN_CLOSE_WRITE,IN_NO_LOOP /root/bin/update.sh "$@$#"
/var/www/html/10/ IN_CLOSE_WRITE,IN_NO_LOOP /root/bin/update.sh "$@$#"
$ cat /root/bin/update.sh
sed -e 's/2019/2020/g' -i "$1"

How to trigger the zillions of incrond processes that will eat the system sooner or later?

sed -e 's/1/2/' -i /var/www/html/100.txt

Afterwards I see lots of incrond processes and when doing nothing but waiting some time, I end up with zillions of incrond processes and load 1000 and when waiting even longer, the system crashes or ends with a kernel panic of khugepaged. Nevertheless the system is dead and needs a hard reset.

karma

When starting incrond now, I see zillions of incrond processes and quite soon afterwards a load of 1000 and more. I did not see such a strange behaviour with incron-0.5.10-8.el7 before.

karma

Works here as expected (tested with private build of gramps-5.0.1-1.el7.noarch)

BZ#1662501 Please build python3-bsddb3 for EPEL 7
BZ#1663442 Rename Request: python-bsddb3 - Python 3 bindings for Berkeley DB