Stephen, The package is singularity. The term "branch" in this context is not very clear to me. All I know is that there's no git branch on pkgs.fedoraproject.org/rpms/singularity; I don't know about other systems. Dave On Tue, Aug 06, 2019 at 03:21:32PM -0400, Stephen John Smoogen wrote: > On Tue, 6 Aug 2019 at 15:10, Dave Dykstra <dwd@xxxxxxxx> wrote: > > > I don't think I understand how epel8-playground is envisioned to be > > used. I did the fedpkg request-branch epel8 and got it created for my > > package. I also ran fedpkg request-branch epel8-playground as in the > > script below, but that was rejected: > > Could not execute request_branch: You cannot directly request > > epel8-playground branch, as they are created as part of epel branch requests > > > > > An epel8-playground branch should have been created when the epel8 one was > done. This means something broke when the original package branch was > requested. What was the package(s)? so I can track down what is broken? > > > > > However, the epel8 branch got created, and in git there was a > > package.cfg containing "targets = epel8 epel8-playground". With that I > > was able to do "fedpkg build --target epel8-playground", but there is no > > epel8-playground git branch, and in fact if I try to create one and push > > it to the server it gets rejected > > remote: Unspecified ref refs/heads/epel8-playground is blocked > > ... > > ! [remote rejected] HEAD -> epel8-playground (pre-receive hook > > declined) > > So apparently epel8-playground has to share the epel8 git branch, and > > you can build it in koji, but I don't understand what the value is in > > that. How is that different than building it for the epel8 koji target, > > as long as you don't request that it get put into the testing yum > > repository? > > > > Dave > > > > On Thu, Aug 01, 2019 at 01:33:55PM -0400, Stephen John Smoogen wrote: > > > Subject: Re: [EPEL-devel] EPEL-8 package requests are now open > > > I would like to thank everyone for their patience and for the people who > > > have put in a lot of work to get us to where we can start building > > > packages. The following is a general outline of what we have for > > packaging > > > procedures for EPEL-8. The master document is currently at > > > https://hackmd.io/@ssmoogen/B1p2QM-eS It will be stored with other EPEL > > > documents shortly. > > > > > > # EPEL-8 Packaging Procedures > > > > > > ## Introduction > > > > > > When a new Red Hat Enterprise Linux occurs, one of the steps to get EPEL > > > going for it is branching of various packages into new namespace. The > > EPEL > > > Steering Committee does not mass branch all existing packages into the > > > namespace because it has caused multiple problems: > > > 1. The package maintainers did not want to support the package in the > > newer > > > version of EPEL. Package maintainers may only want to support certain > > > versions of Enterprise Linux or may want to wait until their favourite > > > derivative appears. > > > 2. The package does not work in the latest version of RHEL. With multiple > > > years between releases, software which worked on Fedora 18 which would > > > branch to EPEL-7 may not exist anymore with Fedora 28 and EPEL-8 would > > need > > > a completely different version. > > > > > > ## Consumer request for packages > > > > > > People who are interested in getting packages into EPEL should contact > > the > > > package maintainer through [bugzilla](https://bugzilla.redhat.com/ ). > > This > > > allows for the requests to be tracked and if the primary maintainer is > > not > > > interested in branching to EPEL, other ones can step in and do so. > > > > > > ## EPEL Playground > > > > > > We have added an additional set of channels for EPEL-8 called playground. > > > It is meant to be sort of like Fedora Rawhide so that packagers can work > > on > > > versions of software which are too fast moving or will have large API > > > changes from what they are putting in the regular channel. > > > > > > To try and make this transparent, we have made it so 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 2 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 primarily to be used in the following > > > manner: > > > > > > * To test out some new version of the package that might not be stable > > yet. > > > * To test out some new packaging of the package > > > * To test a major version change of the package that they want to land at > > > the next epel8 minor release. > > > * To build a package that will never be stable enough for epel8, 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 epel8 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 also you want to make sure it's panned out, > > > so you can test before hand in playground. > > > > > > Consumers should be aware that packages in EPEL8-playground are there > > > without any Service Level Expectations. You may want to only cherry pick > > > packages from there as needed. > > > > > > ## Developer request for branching multiple packages > > > > > > 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 foo bar goo blah blech > > > 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 Issues > > > > > > 1. /usr/bin/python does not exist. Choose ``/usr/bin/python3`` or > > > ``/usr/bin/python2`` and patch appropriately. > > > 2. ``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. > > > 3. 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. > > > 4. ``systemd-rpm-macros`` is not a separate packages. If needed, used > > > ``BuildRequires: systemd`` > > > 5. While EL-8 comes with platform-python, it should NOT be used in > > > ``Requires:`` unless absolutely neccessary. python3 should be used > > instead. > > > (Exceptions can be made but will be rare and need justification.) > > > **Accepted Exceptions:** > > > * Use python3.6dist(coverage) instead of python3-coverage. This package > > is > > > not shipped but is needed in %check code. > > > 6. 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 only suggest one choice: > > > * Choose not to have the python2 part of your package and patch whatever > > > to use python3. > > > 7. 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. > > > 8. While a RHEL src.rpm might produce a -devel package, it may not > > > currently be in the build repository. 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. After modularity is > > > enabled, changes to what is done will be needed. > > > 9. EPEL-8.0 may not work with the RHEL-8.1 beta. There seem to be changes > > > in dnf and zchunk which we have not worked out. This line will be > > updated. > > > 10. 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. > > > > > > > > > ## Definitions > > > > > > 1. 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. > > > 2. Consumer. A person who has subscribed to EPEL for packages but is not > > a > > > maintainer. > > > 3. 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. > > > -- > > > Stephen J Smoogen. > > > > > _______________________________________________ > > > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > > > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > > _______________________________________________ > > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > > > > > -- > Stephen J Smoogen. > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
