Language Selection

English French German Italian Portuguese Spanish

Announcing EPEL-8.0 Official Release

Filed under
Red Hat

The EPEL Steering Committee is pleased to announce that the initial EPEL-8 is ready for release. We would like to thank everyone in the community for helping us get the initial set of builds out to mirrors and to consumers worldwide. Special thanks go to Patrick Uiterwijk, Jeroen van Meeuwen, Robert Scheck, and many others in the community who helped in the last 6 months to get this release done.

EPEL-8.0 has packages for the x86_64, ppc64le, aarch64, and now the s390x platforms.
What is EPEL?

EPEL stands for Extra Packages for Enterprise Linux and is a subcommunity of the Fedora and CentOS projects aimed at bringing a subset of packages out of Fedora releases ready to be used and installed on various Red Hat Enterprise Linux (RHEL). It is not a complete rebuild of Fedora or even of previous EPEL releases. EPEL is also a community and not a product. As such we need community members to help get packages into the repository more than done in Fedora.

Read more

The full E-mail message

  • EPEL 8.0 released
    The EPEL Steering Committee is pleased to announce that the initial
    EPEL-8 is ready for release. We would like to thank everyone in the
    community for helping us get the initial set of builds out to mirrors
    and to consumers worldwide. Special thanks go to Patrick Uiterwijk,
    Jeroen van Meeuwen, Robert Scheck, and many others in the community
    who helped in the last 6 months to get this release done.
    
    EPEL-8.0 has packages for the x86_64, ppc64le, aarch64, and now the
    s390x platforms.
    
    ## What is EPEL?
    
    EPEL stands for Extra Packages for Enterprise Linux and is a
    subcommunity of the Fedora and CentOS projects aimed at bringing a
    subset of packages out of Fedora releases ready to be used and
    installed on various Red Hat Enterprise Linux (RHEL). It is not a
    complete rebuild of Fedora or even of previous EPEL releases. EPEL is
    also a community and not a product. As such we need community members
    to help get packages into the repository more than done in Fedora.
    
    If you are interested in getting a package into EPEL, contact the
    package maintainer through bugzilla. This way the request can be
    tracked, and if the primary maintainer is not interested in branching
    to EPEL, others can step in and do so. Optionally you can send a
    request to the epel-devel@lists.fedoraproject.org mailing list. If you
    do so, please include why the package is needed, to help other
    volunteers decide whether they can support it.
    
    ## What is new?
    
    ### Playground for Rawhide like things
    We have added an additional set of channels for EPEL-8 called
    playground. It is similar to Fedora Rawhide so packagers can work on
    versions of software that are too fast moving or will have large API
    changes compared to versions in the regular channel.
    
    To make this purpose transparent, when a package is built in epel8, it
    will normally also be built in epel8-playground. This is done via a
    packages.cfg file which lists the targets for fedpkg to build against.
    A successful package build will then go through two different paths:
    * epel8 package will go into bodhi to be put into epel8-testing
    * epel8-playground will bypass bodhi and go directly into
    epel8-playground the next compose.
    
    If a packager needs to focus only on epel8 or epel8-playground they
    can edit packages.cfg to change the target=epel8 epel8-playground to
    target=epel8.
    
    Packages in epel8-playground are intended to be used in the following manner:
    * To test out a new version of the package that might not be stable yet.
    * To test out new packaging of the package
    * To test a major version change of the package intended for the next
    EPEL-8 minor release.
    * To build a package that will never be stable enough for EPEL-8, but
    still could be useful to some.
    
    At minor RHEL releases (ie, 8.1, 8.2) people can pull in big changes
    from playground to the main EPEL-8 packages. Since people will be
    upgrading and paying more attention than usual anyhow at those points,
    it’s a great chance to do that change, but you can test beforehand in
    the playground to make sure these changes work.
    Consumers should be aware that packages in EPEL8-playground are
    without any Service Level Expectations. You may want to only cherry
    pick packages from the playground as needed.
    
    ### New Architecture: s390x
    
    We have added the s390x platform to builds. Some consumers have wanted
    this platform for many years but we did not have the time to integrate
    necessary changes. We have done this with EPEL-8, and hope to be able
    to do so for EPEL-7 if there are continued requests for it.
    
    ## What is next? (Why is it called EPEL-8.0?)
    The goal for EPEL-8.1 will be implementing modules into the
    repository, which allows builds for packages that depend on
    non-shipped devel packages. It also allows maintainers to supplement
    and replace other packages they could not under standard EPEL rules.
    
    ## Known Issues:
    1. EPEL-8.0 does not come with modules. Packages built for perl,
    python and other modules are only built against “default” modules. For
    example installing a perl library from EPEL will work with the
    perl-5.26 but not with the perl-5.24 module.
    2. RHEL-8.0 and RHEL-8.1 beta do not come with the same packages in
    all architectures. There are 720 ‘desktop’ packages which were only
    shipped for x86_64 and ppc64le. Packagers looking to deliver GNOME,
    KDE, or other platforms will need to exclude s390x and aarch64 at this
    time.
    3. The dnf in RHEL-8.1 beta does not work with the EPEL repository due
    to zchunk code. This has been opened as an upstream bug as
    https://bugzilla.redhat.com/show_bug.cgi?id=1719830
    4. Until modularity and module builds are implemented in EPEL, there
    will be many packages which can not be built for EPEL. This is mainly
    due to RHEL-8 not shipping many -devel packages and the need for us to
    rebuild those packages in a module to make those -devel available to
    build against. When running into this please open a ticket with
    https://pagure.io/epel/new_issue for us to put in a request for it to
    be added to Red Hat’s Code Ready Builder. Please list the package(s)
    which is blocked from being built because of its absence. We will
    collate these items into bugzilla tickets which will be reviewed by
    the Red Hat product groups to see if they will be added in future Code
    Ready Builder releases. Doing this will ensure that we do not have 70
    requests for foo-devel but can have one with all the packages needing
    it.
    5. /usr/bin/python does not exist in RHEL8. Developers should aim
    towards /usr/bin/python3 or /usr/bin/python2 and patch appropriately.
    Python2 packages are discouraged. RHEL-8 will contain python2.7 until
    probably the end of life of RHEL-7. However support upstream will only
    be minimal. When modularity occurs, we suggest that you make whatever
    python2 packages modules which can be pulled out when RHEL-8.N no
    longer has python2.
    6. python2-sphinx is not shipped. Most packages should work with
    python3-sphinx, and if it doesn’t please open a bug. The python team
    has been good about making fixes for this.
    7. When branching python packages, be aware that python in EL-8 is
    python36 and not the version currently in rawhide. This has come up
    with a couple of test packages where they assumed python37 or later.
    8. While EL-8 comes with platform-python, it should NOT be used in
    Requires: unless absolutely necessary. python3 should be used instead.
    (Exceptions can be made but will be rare and need justification.)
      * Accepted exception: Use python3.6dist(coverage) instead of
    python3-coverage. This package is not shipped but is needed in %check
    code.
    10. Sometimes RHEL8 only has a python3 package for a dependency you
    need for your build. (Example: python-bleach requires
    python2-html5lib, but RHEL8 provides only python3-html5lib). For
    EPEL-8.0 we recommend strongly to only focus on python3 subpackages..
    11. RHEL-8 was built with packages which were not shipped. In general
    it is OK to branch these packages and build them in EPEL.
    12. systemd-rpm-macros is not a separate packages. If needed, used
    BuildRequires: systemd
    13. You will need to make sure you have a version of fedpkg greater
    than fedpkg-1.37-4 to work with both `epel8` and `epel8-playground`.
    Versions before that should work with just `epel8`.
    
    ## Developer requests for multiple branches
    Branching is handled the same way as requesting a branch using fedpkg
    request-branch. A maintainer can request an epel8 branch using fedpkg
    request-branch epel8 which will create a ticket in
    https://pagure.io/releng/fedora-scm-requests/issues and Release
    Engineering will process these requests.
    To branch multiple packages please use this or a variant of this script:
    
    ```
    #!/usr/bin/sh
    # Reminder to get an updated pagure token for releng tickets
    # Usage: epel-8.sh package1 package2 package3 package4
    if [ $# -lt 1 ]
    then
        echo "At least one package name should be provided"
    else
        TMPDIR=`mktemp -d /tmp/epel8.XXXXXX`
        pushd "$TMPDIR"
        for pkg in "$@"
        do
            fedpkg clone "$pkg"
            pushd "$pkg"
            fedpkg request-branch epel8
            fedpkg request-branch epel8-playground
            popd
        done
        rm -rfv "$TMPDIR"
    fi
    ```
    
    Releng will then work through the tickets in the system which is
    adding branches to the PDC and src.fedoraproject.org.
    
    ## Known RHEL-8 packages missing -devel
    * libblueray-devel
    * liba52-devel
    * libXvMC-devel
    * libdvdnav-devel
    * gfbgraph-devel
    * libuv-devel
    * rest-devel
    * qgpgme-devel
    
    ## Definitions
    * Package maintainer. Person who has accepted responsibility to
    package and maintain software in the Fedora Project ecosystem. The
    main packager is usually someone focused on Fedora Linux, and
    secondary packagers may be focused on particular use cases like EPEL.
    * Consumer. A person who has subscribed to EPEL for packages but is
    not a maintainer.
    * PDC. Product Definition Center. A tool to help list the lifetime and
    permissions that a product has so that branching and updates can be
    better managed.
    
    
    

Now covered by Michael Larabel

  • EPEL 8.0 Is Now Ready To Offer Up More Packages To Red Hat Enterprise Linux 8 Users

    EPEL 8.0 is now ready for users of Red Hat Enterprise Linux 8 and the eventual CentOS 8 for complementing the standard repositories with extra packages for what is found in Fedora.

    The "Extra Packages for Enterprise Linux" continues providing a sub-set of Fedora's packages to RHEL/CentOS users. Just as they've done for prior RHEL series, EPEL 8.0 provides updated/additional packages for Red Hat Enterprise Linux 8.0 / CentOS 8.0 users.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

OSS Leftovers

  • This Program Makes It Even Easier to Make Deepfakes

    A new method for making deepfakes creates realistic face-swapped videos in real-time, no lengthy training needed. Unlike previous approaches to making deepfakes—algorithmically-generated videos that make it seem like someone is doing or saying something they didn’t in real life—this method works on any two people without any specific training on their faces. Most of the deepfakes that are shared online are created by feeding an algorithm hundreds or thousands of images of a specific face. The algorithm "trains" on that specific face so it can swap it into the target video. This can take hours or days even with access to expensive hardware, and even longer with consumer-grade PC components. A program that doesn’t need to be trained on each new target is another leap forward in making realistic deepfakes quicker and easier to create. [...] On their project website, the researchers say that the project code will eventually be available on GitHub...

  • 5 Free and Open Source CRM Software

    We’re here to save you time by going over some of the most popular free and open source CRM solutions and when you should consider paid system...

  • A free/open tool for making XKCD-style "hand-drawn" charts

    Tim Qian, a "full stack developer and open source activist," has published chart.xkcd, a free/open tool that lets you create interactive, "hand-drawn" charts in the style of XKCD comics. It's pretty fabulous!

  • The Secret Source: Machine Learning and Open Source Come Together

    There was a time when banks and asset managers would dare not talk about their use of AI—and, specifically, machine learning—in public forums, as they either viewed it as taboo or they wanted to hide its power from competitors. The secret, though, is out of the black box.

  • How China became a hero in open source

    China was once a relative zero when it came to software. Not anymore. In both proprietary and open source development, China's influence is growing. Sure, open source has helped to fuel that rise—as Swim.ai CTO Simon Crosby has suggested, "Now [China] can download our best, for free, every day"—but this tells an incomplete story. China may have been a net consumer of code once upon a time, but now has gone from zero to hero in open source.

  • The 7 Best Tools for Open-Source Network Bandwidth Monitoring

    Network bandwidth monitoring is a very specific type of monitoring. What it does is measure the amount of traffic passing a given point on a network. Typically, the measuring point is a router or switch interface but it’s not uncommon to monitor bandwidth utilization of a server’s LAN interface. The important thing here is to realize that all we’re measuring is the amount of traffic. Bandwidth monitoring won’t give you any information about what that traffic is, only how much of it there is. There are several reasons for wanting to monitor network bandwidth utilization. First and foremost, it can help you pinpoint areas of contention. As a network circuit’s utilization grows, its performance starts degrading. This is a fact of life. The more you approach the maximum capacity, the more impact there is on performance. By allowing you to keep an eye on network utilization, bandwidth monitoring tools give you a chance to detect high utilization—and address it—before it becomes noticeable by users. Capacity planning is another major benefit of network monitoring tools. Network circuits—especially long-distance WAN connections—are expensive and will often have only the bandwidth that was required when they were initially installed. While that amount of bandwidth might have been OK back then, it will eventually need to be increased. By monitoring the evolution of your network circuits’ bandwidth utilization, you’ll be able to see which ones need to be upgraded and when. Bandwidth monitoring tools can also be useful for troubleshooting poor application performance. When a user complains that some remote application has slowed down, looking at the network bandwidth utilization can give you a pretty good idea whether or not the problem is caused by network congestion. If you see low network utilization, you can likely concentrate your troubleshooting efforts elsewhere.

  • Au Revoir DTW

    While I wanted to use it for my tiny, crazy, work in progress thoughts, I find that it was increasingly being subsumed by my new shiny Mastodon. And as the volume of things I write now scales up, I do not want another place to maintain.

  • How To Promote Real Social Good

    It was big news this week when the nation’s most powerful chief executives finally acknowledged that corporations should contribute more to society than maximizing shareholder value. [...] This news story caught our attention here at Purism because we have been thinking about how to build a company that promotes social good. Our company was incorporated in Washington State as a Social Purpose Corporation. [...] We at Purism are grateful to the many US states offering to give companies the freedom to actually benefit society, rather than contribute to its ills. We believe that consumers who really care about their freedom, privacy, and security, or other issues like climate change, seek out companies like ours that exist, first and foremost, to do something important that can better people’s lives. We use capitalism, and the corporate form, to build a sustainable company that can continue to serve our mission. Making money is a means to an end, not the end itself. We exist for our customers, not for our shareholders, and our shareholders back us because know the social good that comes from our efforts. People parting with their hard-earned money for products and services deserve that much.

Security Leftovers

  • Security Researchers Find Several Bugs in Nest Security Cameras

    Researchers Lilith Wyatt and Claudio Bozzato of Cisco Talos discovered the vulnerabilities and disclosed them publicly on August 19. The two found eight vulnerabilities that are based in the Nest implementation of the Weave protocol. The Weave protocol is designed specifically for communications among Internet of Things or IoT devices.

  • Better SSH Authentication with Keybase

    With an SSH CA model, you start by generating a single SSH key called the CA key. The public key is placed on each server and the server is configured to trust any key signed by the CA key. This CA key is then used to sign user keys with an expiration window. This means that signed user keys can only be used for a finite, preferably short, period of time before a new signature is needed. This transforms the key management problem into a user management problem: How do we ensure that only certain people are able to provision new signed SSH keys?

  • Texas ransomware attacks deliver wake-up call to cities [iophk: Windows TCO]

    The Texas Department of Information Resources has confirmed that 22 Texas entities, mostly local governments, have been hit by the ransomware attacks that took place late last week. The department pointed to a “single threat actor” as being responsible for the attacks, which did not impact any statewide systems.

  • Texas Ransomware Attack

    On Security Now, Steve Gibson talks about a huge ransomware attack. 23 cities in Texas were hit with a well-coordinated ransomware attack last Friday, August 16th.

  • CVE-2019-10071: Timing Attack in HMAC Verification in Apache Tapestry

    Apache Tapestry uses HMACs to verify the integrity of objects stored on the client side. This was added to address the Java deserialization vulnerability disclosed in CVE-2014-1972. In the fix for the previous vulnerability, the HMACs were compared by string comparison, which is known to be vulnerable to timing attacks.

GNOME Feeds is a Simple RSS Reader for Linux Desktops

Feedreader, Liferea, and Thunderbird are three of the most popular desktop RSS readers for Linux, but now there’s a new option on the scene. GNOME Feeds app is simple, no-frills desktop RSS reader for Linux systems. It doesn’t integrate or sync with a cloud-based service, like Feedly or Inoreader, but you can import a list of feeds via an .opml file. “Power” users of RSS feeds will likely find that GNOME Feeds a little too limited for their needs. But the lean feature set is, arguably, what will make this app appeal to more casual users. Read more

GNU Radio Launches 3.8.0.0, First Minor-Version Release In Six Years

The GNU Radio maintainers have announced the release of GNU Radio 3.8.0.0, the first minor-version release of the popular LimeSDR-compatible software defined radio (SDR) development toolkit in over six years. “It’s the first minor release version since more than six years, not without pride this community stands to face the brightest future SDR on general purpose hardware ever had,” the project’s maintainers announced this week. “What has not changed is the fact that GNU Radio is centred around a very simple truth: Let the developers hack on DSP. Software interfaces are for humans, not the other way around. And so, compared to the later 3.7 releases, nothing has fundamentally modified the way one develops signal processing systems with GNU Radio: You write blocks, and you combine blocks to be part of a larger signal processing flow graph.” Read more