Kevin Fenzi wrote:
On 2/3/19 11:48 AM, Stephen John Smoogen wrote:
Over the weekend, tmz asked on IRC why their RHEL-6 build was failing when it had not failed previously. The problem was that the expat21 package was being seen in the buildroot and over-riding the RHEL-6 expat.
https://koji.fedoraproject.org/koji/rpmlist?buildrootID=15142150%20&star...
This was due to a bug in the expat21 package, but the part that I am trying to figure out is why the following packages are shown as "internal" in the buildroot.
expat21-2.1.0-1.el6.x86_64.rpm internal expat21-devel-2.1.0-1.el6.x86_64.rpm internal highlight-3.8-1.el6.x86_64.rpm internal pcre2-10.21-22.el6.x86_64.rpm internal pcre2-devel-10.21-22.el6.x86_64.rpm internal perl-IO-Tty-1.08-3.el6.x86_64.rpm internal
The following do make sense:
epel-release-6-8.noarch.rpm internal epel-rpm-macros-6-21.noarch.rpm internal python2-rpm-macros-3-13.el6.noarch.rpm internal python-rpm-macros-3-13.el6.noarch.rpm internal python-srpm-macros-3-13.el6.noarch.rpm internal
Are the above items where the buildrequires in a package are pulling them in or is there a buildroot directive adding them?
"internal" here means local to koji, ie, in epel.
expat21 is in epel. I have no idea why this bug wouldn't have hit before, as expat21 hasn't been changed in many years, but it is in epel.
I'm not sure either, but until recently (in the past month or two), this didn't affect koji. It still does not affect builds on el6 either via mock from a fedora host or directly via rpmbuild.
For the local el6 builds, I used fedpkg --release el6 srpm and then yum-builddep on the srpm to install the deps.
However, Carl George filed a bug report on this last June:
https://bugzilla.redhat.com/show_bug.cgi?id=1585248
In that report he noted that yum-builddep was a symlink to dnf-utils. On the f27/f28/f29 systems I tested, yum-utils had been installed, so perhaps that is one of the important differences which keeps this from affecting normal epel users and many local/mock builds?
Installing epel-release and then running yum install expat-devel also doesn't pull in expat21. I thought this might be because expat from base is already installed, so I installed expat-devel-2.0 and then ran yum update expat-devel and still don't get expat21 pulled in.
In any case, is there an audit trail that shows when (and perhaps why) expat21 was added to the internal koji repo? It seems like it should be removed from there if it's manually tagged into that location.
Björn, have you had any luck on the CVE's affecting expat21 so an update dropping the expat-devel provides can be submitted?