The following Fedora EPEL 6 Security updates need testing:
Age URL
18 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12f1eb1b1f tomcat-7.0.94-1.el6
The following builds have been pushed to Fedora EPEL 6 updates-testing
pythia8-8.2.43-1.el6
root-5.34.38-3.el6
Details about builds:
================================================================================
pythia8-8.2.43-1.el6 (FEDORA-EPEL-2019-2e05134b0a)
Pythia Event Generator for High Energy Physics
--------------------------------------------------------------------------------
Update Information:
* pythia8 8.2.43 * root rebuilt against new pythia8
--------------------------------------------------------------------------------
ChangeLog:
* Fri Jul 5 2019 Mattias Ellert <mattias.ellert(a)physics.uu.se> - 8.2.43-1
- Update to version 8.2.43
- Add Python 3 package for EPEL 6
- Remove ppc64 specific conditionals (ppc64 no longer built in Fedora or EPEL)
* Tue Jun 11 2019 Mattias Ellert <mattias.ellert(a)physics.uu.se> - 8.2.35-8
- Use python-embed pkg-config module if it exists (python 3.8 compatibility)
* Thu Mar 7 2019 Troy Dawson <tdawson(a)redhat.com> - 8.2.35-6
- Rebuilt to change main python from 3.4 to 3.6
* Wed Feb 6 2019 Mattias Ellert <mattias.ellert(a)physics.uu.se> - 8.2.35-7
- Reduce memory usage during compilation of the python module on 32 bit arm
* Sat Feb 2 2019 Fedora Release Engineering <releng(a)fedoraproject.org> - 8.2.35-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
--------------------------------------------------------------------------------
================================================================================
root-5.34.38-3.el6 (FEDORA-EPEL-2019-2e05134b0a)
Numerical data analysis framework
--------------------------------------------------------------------------------
Update Information:
* pythia8 8.2.43 * root rebuilt against new pythia8
--------------------------------------------------------------------------------
ChangeLog:
* Fri Jul 5 2019 Mattias Ellert <mattias.ellert(a)physics.uu.se> - 5.34.38-3
- Rebuild for pythia8 8.2.43
- Use correct library names in plugin definitions
- Fix build failure due to that newer libXrdCl requires c++11
--------------------------------------------------------------------------------
# Update on EPEL-8 Status
## Why is EPEL-8 Taking So Long (tl;dr:)
1. Getting koji to work smoothly with modules has been hard. A multi-level
fix has had to be worked to get it working in staging.
* Needed a way to split out default modules to deal with koji merge
options. [Grobisplitter](https://github.com/puiterwijk/grobisplitter) was
written to do this
* [Koji](https://pagure.io/koji) needed further patching to deal with
src.rpms with same NVR but different targets (some python2 and python3 come
from same src.rpm but were built in different times).
* DNF reposync from RHEL-7 would delete the wrong files if you tried the
``--newest`` (fixed.)
* DNF does not know how to reposync modules if it is not the local arch.
Code Ready Builder is not always in sync with packages in main trees. If
you need a -devel and it isn’t in CRB, then you have to wait until it is
there to build something.
2. As a couple of fixes landed in mergerepo and koji, we are re-evaluating
how we do builds in the next stage of building.
## Introduction
In May of 2019, Red Hat released their 8.0 release of Red Hat Enterprise
Linux (RHEL). Usually, the Extra Packages for Enterprise Linux (EPEL) group
would have a beta available at that time or sooner. With RHEL-8, it has
taken a lot longer to get things rolling.
## Repository Changes
EPEL packages are built inside of the Fedora Projects' build
infrastructure. This is done by downloading the packages from Red Hat's
public Content Delivery Network (CDN), and then having the Fedora artifact
build system (koji) use the release as an external build channel. Koji
looks at packages in a different way than other build commands like 'mock'
do. Where mock is meant to just build packages, koji is designed about
auditing the entire lifecycle of a package. In other words, if you want to
know how a package in Fedora 12 was built and all its children interacted
over time in the buildroots.. you can do that with enough work and the koji
databases. With mock you have a couple of log files which tell you what was
pulled into a buildroot but how those were built would require you finding
their log files, etc etc. A developer can also download those packages and
look at them to see what was in them and how they were built.
The strength of koji is that you can have a credible chain of builds to
know where things came from. However this doesn't work too well with
building packages for EPEL where koji doesn't know where the RHEL kernel
came from. Koji uses mergerepo to look at the external packages provided,
determines the src.rpm they would come from and determines what the latest
version it would use from each. From this it creates a 'buildroot' which it
will use to build packages from. This has worked pretty well for building
packages from RHEL-5,6, and 7. The major downside has been where someone
built a package with the same src.rpm name which koji then decides is the
master no matter if a newer version shows up in RHEL.
This all changed with modularity. Koji really only has a rudimentary idea
of rpms and repositories.. it has zero idea about modules and the rules it
has used to determine what an external package is are thrown out with
modules.
1. Packages with different names may come with from the same src.rpm. In
RHEL-8 many python27 and python36 packages have the same parent src.rpm but
were in different build times. Koji's standard repo comparison mode will
choose one or the other.
2. Packages may have the same names-version-releases but were built in
different module streams (say perl-5.26 and perl-5.24) Koji would then
choose a package depending on whatever had the largest src.rpm which meant
it could try to build a buildroot with perl-5.24 perl modules but
perl-5.26 as the master perl.
If a developer uses mock to build a package with default repositories, mock
calls dnf which knows about modules and does the right thing. In the case
where you want it to do the 'wrong' thing you can also over-ride mock to do
that. With koji, further tools are needed to make this work. If you are
building a new module, then the Modular Build System (MBS) sits on top of
koji and tells koji what to do. It will look at the module yaml file and
turn on/off various modules so that it can build in what is needed. To
build non-modular packages, other fixes are needed. One of these is called
Ursa-Major which was a set of scripts to pull in needed data from a third
database and pull things in as needed. However, this was not adopted in
Fedora for general use so the EPEL group looked for something different.
The temporary solution written by Patrick Uiterwijk is called grobisplitter
(https://github.com/puiterwijk/grobisplitter) which relies on the fact that
modules are virtual repositories embedded in a master repository.
Grobisplitter takes this fact, and uses it to break out 'real' repositories
for each module. So the RHEL-8 repository will look like
```
ant:1.10:820181213135032:5ea3b708:x86_64
container-tools:rhel8:8000020190416221845:2ffa3d27:x86_64
container-tools:rhel8:820190211172150:20125149:x86_64
freeradius:3.0:8000020190425181943:75ec4169:x86_64
freeradius:3.0:820190131191847:fbe42456:x86_64
gimp:2.8:820181213135540:77fc8825:x86_64
go-toolset:rhel8:820190208025401:b754926a:x86_64
httpd:2.4:8000020190405071959:55190bc5:x86_64
httpd:2.4:820190206142837:9edba152:x86_64
idm:client:820190227213458:49cc9d1b:x86_64
inkscape:0.92.3:820181213140018:77fc8825:x86_64
javapackages-runtime:201801:820181213140046:302ab70f:x86_64
javapackages-tools:201801:820181217165704:dca7b4a4:x86_64
llvm-toolset:rhel8:820190207221833:9edba152:x86_64
mailman:2.1:820181213140247:77fc8825:x86_64
mariadb:10.3:820190206164045:9edba152:x86_64
mariadb:10.3:820190314153642:9edba152:x86_64
maven:3.5:820181213140354:5ea3b708:x86_64
mercurial:4.8:820190108205035:77fc8825:x86_64
merged_repo
mysql:8.0:820190104140943:9edba152:x86_64
nginx:1.14:820181214004940:9edba152:x86_64
nodejs:10:820190108092226:9edba152:x86_64
non_modular
perl-App-cpanminus:1.7044:820181214184336:e5ce1481:x86_64
perl-DBD-MySQL:4.046:820181214121012:6bc6cad6:x86_64
perl-DBD-Pg:3.7:820181214121102:6fcea174:x86_64
perl-DBD-SQLite:1.58:820181214121133:6bc6cad6:x86_64
perl-DBI:1.641:820190116185335:fbe42456:x86_64
perl-FCGI:0.78:820181214153815:fbe42456:x86_64
perl-YAML:1.24:820181214175558:8652dbeb:x86_64
perl:5.26:820181219174508:9edba152:x86_64
php:7.2:820181215112050:76554e01:x86_64
postgresql:10:820190104140132:9edba152:x86_64
python27:2.7:8000020190410132513:c0efe978:x86_64
python27:2.7:820190212161047:43711c95:x86_64
python36:3.6:8000020190410133122:593c47b3:x86_64
python36:3.6:820190123171828:17efdbc7:x86_64
redis:5:820181217094919:9edba152:x86_64
rhn-tools:1.0:8000020190425124933:6ec19280:x86_64
rhn-tools:1.0:820190321094720:e122ddfa:x86_64
ruby:2.5:820190111110530:9edba152:x86_64
rust-toolset:rhel8:820181214214108:b09eea91:x86_64
satellite-5-client:1.0:820190204085912:9edba152:x86_64
scala:2.10:820181213143541:2b79a98f:x86_64
squid:4:820181213143653:9edba152:x86_64
subversion:1.10:820181215112250:a51370e3:x86_64
swig:3.0:820181213143944:9edba152:x86_64
varnish:6:820181213144015:9edba152:x86_64
virt-devel:rhel:820190226174025:9edba152:x86_64
virt:rhel:8000020190510171727:55190bc5:x86_64
virt:rhel:8000020190516125745:55190bc5:x86_64
virt:rhel:820190226174025:9edba152:x86_64
```
In the above, each of those names is the module name, and grobisplitter
would then put the appropriate files in each sub repository. The problem
with this version is that we end up with multiple repositories with some of
them being 'non-default' modules. Building against a non-default module
causes problems for someone trying to install that package. It would
replace packages from a different module than was wanted. Changes to
grobisplitter were made at https://github.com/smooge/grobisplitter to allow
only default modules to be published.
From this we were able to start deploying a devolved tree in the Fedora
staging koji (https://koji.stg.fedoraproject.org/) The first set of fixes
needed was to make it so koji could work with multiple artifacts coming
from the same src.rpm. Instead of using the standard mode for resolving
differences, we import RHEL-8 repositories with a bare mode which is
supposed to use external repository data to determine what should be pulled
in. However, we found that koji still gets confused if multiple versions of
a package are in the repo data. Say your repository contains both
``glibc-*-2.1-2`` and ``glibc-*-2.2-2``. Koji would pull in
``glibc-devel-2.1-2`` and try to match it against ``glibc-2.2-2``. This of
course caused builds to fail.
At first the fix looked to be having the reposync from the CDN pull only
the latest data. However we ran into problems with either the RHEL-7 or
RHEL-8 reposync deleting data we wanted to keep depending on the options
used. Part of this was due to module data and part of it was due to some
bugs in dnf's reposync with other architectures. At this point, it looked
like one of two things needed to be done. One, grobisplitter needs to learn
about package order and pull in just the latest package into a non-modular
repo. Two, another layer of indirection is needed where after we split out
all the repositories we use reposync again to just pull from the grobisplit
repositories. In this case we do so with a ``-n`` and only have the latest
packages. The second option seemed easier to pursue as most of the
grobisplitter toolkit should become irrelevant when the next generation of
Ursa-Major comes out.
## Code Ready Problems
We ran into our next major problem with RHEL-8 repositories when we found
that -devel and -lib rpms in Code Ready Builder were not always in sync
with their parent packages in BaseOS/AppStream. This means that if your
build is wanting kernel-devel and the BaseOS is 4.9-11 but the CRB version
is 4.9-10 then koji has no way to supply the dependency for you. The major
culprit currently is that the virt module has had multiple updates but the
virt-devel module has not had any updates.
## Build Over View
1. RHEL-8 packages are reposync from cdn onto
infrastructure.fedoraproject.org nfs directory.
2. grobisplitter runs on grobisplitter01.phx2.fedoraproject.org to break
out each module into repositories in a ``$date/$arch/$repos`` layout.
3. createrepo is run on ``$date/$arch``
4. a symbolic link is set to ``$date`` staged
5. ``reposync -n -d`` is run against ``staged/$arch`` to ``latest/$arch``
6. createrepo is run on ``latest/$arch``
7. koji points to ``latest/$arch``
8. packages can be built
9. packages can be signed
10. bodhi and other items do their parts
11. we compose
12. ...
13. profit?
## What Are The Next Steps?
Currently we are looking to have our internal beta done by July 1st. At
that point, we will work on documenting what we have done, and
reimplementing the tool changes in production. At which point, developers
will be able to make branch requests to releng to make packages available
and builds should start flowing. From that we will probably find new things
which will need fixes in either spec files or build infrastructure.
A GANNT chart of our current production plan is provided below.
![](https://i.imgur.com/bGiAnHk.png)
--
Stephen J Smoogen.
The following Fedora EPEL 6 Security updates need testing:
Age URL
15 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12f1eb1b1f tomcat-7.0.94-1.el6
The following builds have been pushed to Fedora EPEL 6 updates-testing
davix-0.7.4-1.el6
Details about builds:
================================================================================
davix-0.7.4-1.el6 (FEDORA-EPEL-2019-9885f0b35a)
Toolkit for Http-based file management
--------------------------------------------------------------------------------
Update Information:
New upstream release
--------------------------------------------------------------------------------
ChangeLog:
* Thu Jul 4 2019 Georgios Bitzes <georgios.bitzes at cern.ch> - 0.7.4-1
- New upstream release
--------------------------------------------------------------------------------
The following Fedora EPEL 6 Security updates need testing:
Age URL
14 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12f1eb1b1f tomcat-7.0.94-1.el6
The following builds have been pushed to Fedora EPEL 6 updates-testing
configsnap-0.17.1-1.el6
epson-inkjet-printer-escpr-1.6.41-1.1lsb3.2.el6
fuse3-3.6.1-2.el6
ocserv-0.12.4-1.el6
singularity-3.2.1-1.1.el6
vim-jellybeans-1.7-1.el6
Details about builds:
================================================================================
configsnap-0.17.1-1.el6 (FEDORA-EPEL-2019-c3754a2823)
Record and compare system state
--------------------------------------------------------------------------------
Update Information:
Release 0.17.1 ---- Release 0.17.0
--------------------------------------------------------------------------------
ChangeLog:
* Wed Jul 3 2019 Nick Rhodes <nrhodes91(a)gmail.com> - 0.17.1-1
- Convert relative basedir to absolute path (PR 103)
* Sun Jun 16 2019 Nick Rhodes <nrhodes91(a)gmail.com> - 0.17.0-1
- Update diff function to use Popen.communicate() (PR 101)
* Thu Jan 31 2019 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.16.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
--------------------------------------------------------------------------------
================================================================================
epson-inkjet-printer-escpr-1.6.41-1.1lsb3.2.el6 (FEDORA-EPEL-2019-b5618c7054)
Drivers for Epson inkjet printers
--------------------------------------------------------------------------------
Update Information:
Update to 1.6.41, including more printer drivers.
--------------------------------------------------------------------------------
ChangeLog:
* Wed Jul 3 2019 Susi Lehtola <jussilehtola(a)fedoraproject.org> - 1:1.6.41-1.1lsb3.2
- Update to 1.6.41.
* Thu Jan 31 2019 Fedora Release Engineering <releng(a)fedoraproject.org> - 1:1.6.30-2.1lsb3.2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Tue Oct 9 2018 Susi Lehtola <jussilehtola(a)fedoraproject.org> - 1:1.6.30-1.1lsb3.2
- Update to 1.6.30.
* Thu Jul 12 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1:1.6.20-2.1lsb3.2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1569243 - The version in Fedora does not work with my printer
https://bugzilla.redhat.com/show_bug.cgi?id=1569243
--------------------------------------------------------------------------------
================================================================================
fuse3-3.6.1-2.el6 (FEDORA-EPEL-2019-3ae262c74f)
File System in Userspace (FUSE) v3 utilities
--------------------------------------------------------------------------------
Update Information:
Update to upstream 3.6.1 and newer version of pr #421
--------------------------------------------------------------------------------
ChangeLog:
* Wed Jul 3 2019 Dave Dykstra <dwd(a)fedoraproject.org> - 3.6.1-2
- Update to newer version of pr #421
- Disable building examples on el7
* Thu Jun 13 2019 Tom Callaway <spot(a)fedoraproject.org> - 3.6.1-1
- Update to 3.6.1
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1720238 - fuse3-3.6.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1720238
--------------------------------------------------------------------------------
================================================================================
ocserv-0.12.4-1.el6 (FEDORA-EPEL-2019-6d43b6e26e)
OpenConnect SSL VPN server
--------------------------------------------------------------------------------
Update Information:
Update to upstream 0.12.4 release
--------------------------------------------------------------------------------
ChangeLog:
* Wed Jul 3 2019 Nikos Mavrogiannopoulos <nmav(a)gnutls.org> - 0.12.4-1
- Update to upstream 0.12.4 release
--------------------------------------------------------------------------------
================================================================================
singularity-3.2.1-1.1.el6 (FEDORA-EPEL-2019-f4dc17dadf)
Application and environment virtualization
--------------------------------------------------------------------------------
Update Information:
Add patches for upstream PR #3456 and #3803
--------------------------------------------------------------------------------
ChangeLog:
* Wed Jul 3 2019 Dave Dykstra <dwd(a)fedoraproject.org> - 3.2.1-1.1
- Add patch for PR #3456 to make --home work with 'mount home = no'
- Add patch for PR #3803 to make bind mounts from read-only filesystems
work unprivileged
--------------------------------------------------------------------------------
================================================================================
vim-jellybeans-1.7-1.el6 (FEDORA-EPEL-2019-95a50303cf)
A colorful, dark color scheme for Vim
--------------------------------------------------------------------------------
Update Information:
Latest upstream
--------------------------------------------------------------------------------
ChangeLog:
* Wed Jul 3 2019 Carl George <carl(a)george.computer> - 1.7-1
- Latest upstream
* Sun Feb 3 2019 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.6-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Sat Jul 14 2018 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1723384 - vim-jellybeans-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1723384
--------------------------------------------------------------------------------