HackMD
  • Prime
    Prime  Full-text search on all paid plans
    Search anywhere and reach everything in a Workspace with Prime plan.
    Got it
      • Create new note
      • Create a note from template
    • Prime  Full-text search on all paid plans
      Prime  Full-text search on all paid plans
      Search anywhere and reach everything in a Workspace with Prime plan.
      Got it
      • Sharing Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • More (Comment, Invitee)
      • Publishing
        Everyone on the web can find and read all notes of this public team.
        After the note is published, everyone on the web can find and read this note.
        See all published notes on profile page.
      • Commenting Enable
        Disabled Forbidden Owners Signed-in users Everyone
      • Permission
        • Forbidden
        • Owners
        • Signed-in users
        • Everyone
      • Invitee
      • No invitee
      • Options
      • Versions and GitHub Sync
      • Transfer ownership
      • Delete this note
      • Template
      • Save as template
      • Insert from template
      • Export
      • Dropbox
      • Google Drive
      • Gist
      • Import
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
      • Download
      • Markdown
      • HTML
      • Raw HTML
    Menu Sharing Create Help
    Create Create new note Create a note from template
    Menu
    Options
    Versions and GitHub Sync Transfer ownership Delete this note
    Export
    Dropbox Google Drive Gist
    Import
    Dropbox Google Drive Gist Clipboard
    Download
    Markdown HTML Raw HTML
    Back
    Sharing
    Sharing Link copied
    /edit
    View mode
    • Edit mode
    • View mode
    • Book mode
    • Slide mode
    Edit mode View mode Book mode Slide mode
    Note Permission
    Read
    Only me
    • Only me
    • Signed-in users
    • Everyone
    Only me Signed-in users Everyone
    Write
    Only me
    • Only me
    • Signed-in users
    • Everyone
    Only me Signed-in users Everyone
    More (Comment, Invitee)
    Publishing
    Everyone on the web can find and read all notes of this public team.
    After the note is published, everyone on the web can find and read this note.
    See all published notes on profile page.
    More (Comment, Invitee)
    Commenting Enable
    Disabled Forbidden Owners Signed-in users Everyone
    Permission
    Owners
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Invitee
    No invitee
       owned this note    owned this note      
    Published Linked with GitHub
    Like BookmarkBookmarked
    Subscribed
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    Subscribe
    # 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)

    Import from clipboard

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lost their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template is not available.


    Upgrade

    All
    • All
    • Team
    No template found.

    Create custom template


    Upgrade

    Delete template

    Do you really want to delete this template?

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox

    New to HackMD? Sign up

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Tutorials

    Book Mode Tutorial

    Slide Mode Tutorial

    YAML Metadata

    Contacts

    Facebook

    Twitter

    Feedback

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions

    Versions and GitHub Sync

    Sign in to link this note to GitHub Learn more
    This note is not linked with GitHub Learn more
     
    Add badge Pull Push GitHub Link Settings
    Upgrade now

    Version named by    

    More Less
    • Edit
    • Delete

    Note content is identical to the latest version.
    Compare with
      Choose a version
      No search result
      Version not found

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub

        Please sign in to GitHub and install the HackMD app on your GitHub repo. Learn more

         Sign in to GitHub

        HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Available push count

        Upgrade

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Upgrade

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully