Proposals and such...
by Stephen John Smoogen
Hey I went through my notes and I only have 1 other questioned
proposal that people asked about. I will post that later today but if
there are things people think should have been talked about please let
me know.
--
Stephen J Smoogen.
8 years, 1 month
EPEL Proposal #4: Build it all in CentOS promote to RHEL
by Stephen John Smoogen
==========================================================
EPEL Proposal #4: Build it all in CentOS promote to RHEL
==========================================================
So this one came up when we were going over problems with building
alternative architectures in EPEL. One of the big problems is that
currently everything is built against Red Hat Enterprise Linux. This
has some bonuses for some people but it causes a problem when
architectures are built against by CentOS but not Red Hat. [E.G. EL-7
for i386 and arm32] When a Red Hat release is done, the builders
usually get updated as part of our repopull from the RHN
servers. Usually there are some changes in added and subtracted
packages which can cause packages to get new dependencies. While this
is an inconvenience to customers.. it isn't a problem for the
builders. When we start mixing distributions, it does cause a problem
with the builders because a package may get compiled for EL-7 x86_64
and not be the same as arm32 or i386 due to the fact that buildroots
for i386 are not as up2date as the RHEL ones. This can cause builds
all across the system to break so it is frowned on.
A couple of proposed fixes were:
1. Compile everything against CentOS. This has the bonus that they all
kind of get updated at the same time so breakages from going from
7.3 to 7.4 is smaller. However, a lot of business users have either
ITIL or security plans which allow for EPEL packages to be used on
their systems because they were built against RHEL versus a
rebuild. Remove that and it causes various problems for users.
2. Split off the builds for alternative architectures in a shadow
koji which is turned off when these splits occur. This makes it
partially easier to manage but brings in other problems.
3. some other ways to fix this that I don't know how to describe
correctly
However while we were hashing on 1, someone else who had been asking
about why don't we build everything came up with a
different mix. Build everything against CentOS for various
architectures and put it in some other repository (Extra Packages in
CentOS came to mind). Packages which people really want and are
willing to care for are branched off into EPEL packages which are
built against RHEL. [Or if they really want it they get a business
case to Red Hat to make it a product they will pay for it.]
There is a lot of problems with the above.. it requires a lot of work
in many different moving parts to get done. It also could be even more
confusing than what we have already. However, I did say I was going to
write up all the proposals for people to look at.
--
Stephen J Smoogen.
8 years, 2 months
EPEL Proposal #3: EPEL Structured releases
by Stephen John Smoogen
============================================
EPEL Proposal #3: EPEL Structured releases
============================================
This started off as a a rawhide post, but I realized it needs to be
its own post
A staged/forked environment. This version is a lot more complicated
and deals with extra release management. Currently, Red Hat does
regular point releases (.1, .2, .3) of their main OS. In these point
releases, various items get major updates or backports to bring new
functionality to the base operating system. In this version, EPEL ties
into this staged environment by using a similar method as Fedora does.
Using a directory tree structure like:
EPEL/archives/{5.x, 6.x, 7.x}
EPEL/archives/updates/{5.x, 6.x, 7.x}
EPEL/current/5 -> 5.11/
EPEL/current/5.11/{x86_64,ppc64,x86_32}/
EPEL/current/6 -> 6.7/
EPEL/current/7 -> 7.2/
EPEL/updates/5 -> 5.11/
EPEL/updates/6 -> 6.7/
EPEL/updates/7 -> 7.2/
EPEL/updates/testing/{blah, blah}
EPEL/rawhide/{5, 6, 7}
Then packages would be built in rawhide first. When a new release (say
7.2 to 7.3) occurs, then the builders rawhide trees are updated to the
code in the latest. The packages are built against that and hopefully
tested to see that they still work. Packagers should have been
building any large changes they needed to make in the rawhide tree
already but a last minute notification date is done. The go-live for
this tree will be either when CentOS gets its build out of that tree
or 30 days if CentOS is able to release sooner. On that date the
rawhide trees will be branched to /EPEL/current/{6,7}.n (eg 7.3) and
updates to those packages will now be sent into EPEL/updates/7.3
. After another 30 days, the 7.2 tree will be moved to
EPEL/archives/7.2 {probably really /pub/archives/epel/7.2 }
Pros: this gives a place where newer packages can be built and tested
to see what may break in the next major build. it also gives a
better release cycle that people can plan against.
Cons: this makes the previous post look simple to implement.
--
Stephen J Smoogen.
8 years, 2 months
EPEL Proposal #2: EPEL Rolling Rawhide
by Stephen John Smoogen
========================================
EPEL Proposal #2: EPEL Rolling Rawhide
========================================
An EPEL rawhide may sound like an oxymoron for having an always
building main tree for a release that is known for its plodding
slowness. However there are methods to the madness as people brought
it up at FOSDEM Brussels.
Rolling Release Style. In this version there is a branch where many
Fedora packages are rebuilt against EL-5/6/7. The packages in this
release are always the latest that can be compiled against the release
and all 'updates' and fixes are done upstream versus in the
package. The epel file tree would look something like this:
EPEL/{5,6,7}
EPEL/testing/{5,6,7}
EPEL/rawhide/{5,6,7}
Packages in EPEL/{5,6,7} are ones that are going to be kept stable
until they can no longer be supported. Packages in EPEL/testing/ are
were updates to the mainline packages are kept. The general idea is
that Fedora packagers can freely fork to EPEL/rawhide with no care
about whether it works or not. If people are interested enough to help
fix it they can send it to the packager but if it doesn't build and no
one fixes it.. it isn't there. If people do care about the package,
they can sponsor it and those would be the ones in EPEL regular. These
packages would follow the agreed upon rules about updates and lack of
big changes.
Pros: Allows for more packages to be newer for more users.
Cons: More channels for release engineering and packagers to deal
with.
--
Stephen J Smoogen.
8 years, 2 months
PSA: Enterprise Linux 5 End of Production on 2017-03-31 and EPEL.
by Stephen John Smoogen
===================================================================
PSA: Enterprise Linux 5 End of Production on 2017-03-31 and EPEL.
===================================================================
Red Hat Enterprise Linux builds its current releases around a 4 part
lifecycle model.
* Production 1. New drivers and features are added during this cycle
along with security and production bug fixes.
* Production 2. Only security and production bug fixes are done
during this cycle.
* Production 3. Only security and 'critical' bug fixes are done.
* Extended Lifecycle Support. Security and critical bug fixes are
only released to customers who are paying for this extra level of
support. For rebuild Linuxes like CentOS and Scientific Linux the
product is now End of Lifed.
The last time this happened was in 2012 with the end of life of
Enterprise Linux 4. At that time, EPEL stopped supporting builds for
EL-4 but no other changes were done. This wasn't a big deal because
EL-4 had never gotten a large number of users. However in 1 year, 1
month, EL-5 will reach the end of its production run and move into
Extended Life Support. Enterprise 5 is still over 20% of all EPEL
installs so I wanted to give a long heads up that EL-5 will also be
removed from the builders on April 1 2017 and no builds will be done
after that. Depending on other proposals, EL-5 may also be moved over
to an 'archive' like Fedora releases are so that it is clear that it
is no longer under any production. If that happens there will be clear
notice of where it has been moved to and how to keep at it.
--
Stephen J Smoogen.
8 years, 2 months
Missed Meeting this Week. Please put issues into this email.
by Stephen John Smoogen
I got caught up trying to research a problem with NFS and iscsi and
completely missed that I was supposed to run a meeting today.
Thanks to the people who pinged me and my apologies. Since I am now a
month ahead, I would like to get all the issues that we are wanting
done in the next week meeting (and anything that needed to be done in
this weeks).
Communication Things to be Done:
--------------------------------------------
1. Please read the EPEL documentation on the website and send me
emails about what is broke. I will start compiling that into tickets
into the trac and get them fixed.
2. There is some work on the Fedora side of things to move
documentation out of the wiki and into RST git repositories. Going
from 1 and this I will create a pagure repo that people can work there
or in github.
3. The trac needs work.
4. Blog post on other proposals from people at FOSDEM.
5. .....
Things done:
----------------
1. Tibbs has done a hell of a lot on getting packages to compile
across the board.
2. .....
Things needing input:
--------------------------
1. .....
Other
-------
--
Stephen J Smoogen.
8 years, 2 months
Report on various meetings at FOSDEM.
by Stephen John Smoogen
========================
Apologies and So Forth
========================
First, I would like to apologize for the delay in getting this post
done. I really didn't realize the amount of energy the trip would take
from me and how fuzzy brained I was for a week afterwords. Second, I
would like to thank the Open Source and Standards (OSAS) group at Red
Hat for sponsoring me that week. I believe I got a lot of things done
and that we can work on getting Extra Packages for Enterprise Linux
(EPEL) moving forward in some direction. Third I would like to thank
everyone who took the time to talk to me at one of these places to
tell me about what they were able to do with EPEL and what they were
no longer able to use it for.
One of the items that people brought up a lot was that they felt
conversations about fixing/growing/changing EPEL have become a broken
record. Various things are said at many conferences by various people,
but nothing ever gets done on this to the point that they feel they
have been lied to. After succumbing to the fuzzy headed "what did I
say yesterday?" for a week after flying back, I think that most of
these broken promises have come up from jet-lag and people
overload. If it hadn't been that I had people from IBM, CERN, and
various other groups bring this up over and over again.. I may have
forgotten just as well. In any case, I am going to try and outline
every item that I wrote down on many pages of notes in this blog. If I
have forgotten some point that you wanted me to bring up, please send
me an email so that I can make sure it is dealt with.
===========================
Things EPEL is doing well
===========================
The primary user of EPEL packages are on Red Hat Enterprise Linux (or
a clone like CentOS or Scientific Linux) version 6 with a slowly
shrinking set of EL-5 users. The audiences that use EPEL are very
diverse. Everything from large organizations with strict audit
controls to fast moving startups which have to work with the large
organizations as their customers to the university trying to do some
experiments to match things done in other organizations.
Many users brought up the fact that the win of EPEL is that it is a
low energy move to get packages from Fedora rebuilt for an Enterprise
environment. The fact that the package spec files had been vetted and
tested in Fedora made for less chances of conflicts or configuration
problems that crept into their own spec files or ones they got off the
internet from various groups. Things EPEL is not doing well in
This is going to be a rather long list of items that came up. Some of
them conflict with each other but that is mainly due to the fact that
the customers are so diverse.
* The packaging guidelines for each EPEL version are not clear. This
is mainly due to the fact that they are usually based off of older
versions of Fedora (Fedora-6 for EPEL-5, Fedora-12 for EPEL-6, and
Fedora-18 for EPEL-7) that may conflict with each other or with how
things are being done in current EPEL.
* EPEL does not have a regular release structure like Fedora and RHEL
have. There isn't an EPEL-5.11 channel with an epel-updates-5.11
where updates are available. Because of various repository
limitations, this means that directories aren't able to keep
multiple old copies so downgrades when things do break aren't easy.
* EPEL promises to keep things stable and only update for fixes, but
this is only done on a few packages where others get upgraded to and
fro. There does not seem to be much "steering" or "release
engineering" of what is in the trees.
* EPEL only covers part of Enterprise Linux (the Server product) but a
lot of packages are for the Workstation but there is no way to see
when things replace/conflict with them. [People believe that we
build against the equivalent of CentOS-5/6/7 versus a subchannel.]
* EPEL sometimes has weird breaks between releases. The git in EPEL-5
is newer than what is in EL-6 in a way that was breaking
repositories when pushes were done from EL-5 systems. [People
believe there is a promise that such changes are tested against.]
* EPEL packages disappear. If there is no maintainer packages are
retired but if someone is re-building out the EL-5 hosts.. they need
that package to be available. [People believe there is a promise
that packages will be always available.]
* From various people who were (or former) EPEL maintainers: packages
in EPEL are the most complained about. If they can't update the
package in EPEL, they get complaints about it being too old and they
may end up having a newer version available for what they need to do
anyway. If they do update the version, they get complaints that they
broke someone because they needed some old version. Most of the
complaints usually are the worst kinds ( off-hand death threats (why
don't you die in a fire) etc etc).
==============================
Things people wanted in EPEL
==============================
There were various things that people were wanting in EPEL that
weren't really breakages because they don't exist yet.
* Enable 'alternative' architectures. There were requests from people
about CentOS-i386 and CentOS-arm (for the Raspberry Pi2 in schools)
with no vision on how those would be enabled.
* Enable more packages with shorter lifetimes. One of the things that
multiple sites were doing was rebuilding all of a Fedora release for
their internal mirrors to supplement all of the things that EPEL
didn't have in it. Why can't there be an EPEL-rawhide where all of
these packages are built but no 'promises'?
* Is it possible to have a branch management system where packages get
updated regularly? Say either whenever Fedora moves to a new release
or Red Hat updates to the next branch (6.7->6.8, 7.2->7.3)
* Could packages in EPEL be tested in the CentOS continuous
integration infrastructure as part of the autokarma testing?
=============
Conclusions
=============
I don't think anything above is new to people who have been
contributing to EPEL in the last ~10 years. A lot of the problems are
ones that were brought up in the beginning as we tried to square the
circle of differing use cases. However, I wanted to catalogue them
here and then make a promise that I will do my best to figure out ways
to solve them by FOSDEM 2017 in some form or another.
As I said at the beginning of the post, I believe that people had
other complaints and suggestions. If I forgot or miswrote, my
apologies and I will correct.
--
Stephen J Smoogen.
8 years, 2 months
python2-rsa is broken
by Rabe, Jens
Hello,
I tried to install python2-rsa from EPEL in a CentOS 6.7 x86-64 system, and it fails with this dependency error:
Error: Package: python2-rsa-3.3-2.el6.noarch (epel)
Requires: python-pyasn1 >= 0.1.3
Available: python-pyasn1-0.0.12a-1.el6.noarch (base)
python-pyasn1 = 0.0.12a-1.el6
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Is there currently a fix for that?
8 years, 2 months