[EPEL-devel] Re: proposal: EPEL 8 Next
On Wed, Sep 9, 2020 at 2:50 PM Petr Pisar wrote: > I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it > is to be use with Stream, why don't we call it EPEL 8 Stream? I think the > meaning of the repository would be easier to understand. Agreed. Using the "Stream" suffix is much easier to understand. In fact, it is obvious. and, keep in mind: The first thing, we want to differ would be epel-release. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[EPEL-devel] Re: proposal: EPEL 8 Next
At the EPEL Steering Committee last week, we had an extensive discussion of this proposal, specifically focused on how to handle the dist macro. I believe these are the possible choices. * keep dist the same as epel8 (.el8) RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for dist. It would make sense to continue using the same dist for EPEL Next. However, this would put a little more work on packagers. They would not be able to build the same commit for both EPEL and EPEL Next because the NVR will conflict in Koji. In simple rebuild situations, this is not a problem because at a minimum the release will be higher. But if a packager wanted to update the package in both EPEL and EPEL Next, they will need to first update and build it in EPEL, then bump the release and build it in EPEL Next. This isn't ideal, but isn't terrible either, and can be partially mitigated by good documentation around EPEL Next workflows. * modify dist to always be higher than epel8 (.el8.next or similar) In EPEL Next we could define dist to a string that RPM evaluates higher than .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be in sync and the same commit could be built for both targets. The higher dist would ensure the upgrade path works. * modify dist to reflect future rhel version (.el8_3) This is similar to the previous choice as far as the upgrade path. It would make things a bit more obvious during the CentOS Linux rebuild gap. For example, a user who upgrades from RHEL 8.2 to 8.3 could grab a .el8_3 build from EPEL Next if the EPEL package hasn't been rebuilt yet. However, the dist could be misleading. Building against CentOS Stream at a given point in time doesn't necessarily give you all the libraries that will be in the next final RHEL minor release. There will be situations early in the cycle where some libraries have changed and others that will haven't yet. Additionally, there will be a short period of time late in the cycle where CentOS Stream will have release+2 content prior to release+1 reaching RHEL GA. Leaving the minor release out of the dist leaves us more wiggle room on user expectations. We need to make a decision on dist before moving further. Here are some other thoughts from the meeting: - epel-next-release as a subpackage of epel-release - automatic nightly compose or bodhi enablement? - start enumerating the steps necessary to move forward (WIP) On Wed, Sep 9, 2020 at 2:55 PM José Abílio Matos wrote: > > On Wednesday, September 9, 2020 5:56:43 PM WEST Patrick Riehecky wrote: > > > From a mulit-language perspective, I prefer not to use '4' in place of > > > the English word 'for'. It makes the translation work a bit wonky. > > > Not only that, do not forget the meaning/association of 4 in different > cultures. :-) > > > -- > > José Abílio > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org -- Carl George ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[EPEL-devel] Re: Proposed EPEL Playground Documentation
On Wed, Sep 16, 2020 at 9:36 AM Kevin Fenzi wrote: > > On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote: > ...snip... > > > > When a maintainer is done with their package in playground, they must > > untag all builds of it out of epel-playground. We do not want > > epel-playground cluttered with old test packages. Done means either > > the package has been moved to regular EPEL, and / or the maintainer no > > longer wants to play and test in epel-playground. Untagging all > > builds of a package is currently done via a release engineering > > ticket. > > This puts more work on releng, but I am not sure how often it will come > up. We could also create a 'epel-sig' permission and grant everyone in > that group permissions to untag from playground? > > Otherwise, looks good to me. > > kevin If the maintainer could do it themselves, I'm ok with that. But currently, I don't think they can. If we can get something better than rel-eng, I'm all for it. But as far as I know, that's what we currently have to do. We can update it when we get something better in place. Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[EPEL-devel] Re: Proposed EPEL Playground Documentation
On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote: ...snip... > > When a maintainer is done with their package in playground, they must > untag all builds of it out of epel-playground. We do not want > epel-playground cluttered with old test packages. Done means either > the package has been moved to regular EPEL, and / or the maintainer no > longer wants to play and test in epel-playground. Untagging all > builds of a package is currently done via a release engineering > ticket. This puts more work on releng, but I am not sure how often it will come up. We could also create a 'epel-sig' permission and grant everyone in that group permissions to untag from playground? Otherwise, looks good to me. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-972f57ea6d drupal7-7.72-1.el6 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b425525e83 mbedtls-2.7.17-1.el6 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83b080a694 proftpd-1.3.3g-15.el6 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-54aaef4451 golang-1.15.2-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing IP2Location-8.0.9-9.20200916git6e49424.el6 Details about builds: IP2Location-8.0.9-9.20200916git6e49424.el6 (FEDORA-EPEL-2020-f04ff49b16) C library for mapping IP address to geolocation information Update Information: subpackage data-sample: add suffix "SAMPLE" to included BIN files, fix file permissions add patch to sync with upstream ChangeLog: ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 763 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 503 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-49c5f31e92 python-pip-epel-8.1.2-14.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-864bc6779e chromium-85.0.4183.83-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83bdeb2965 ansible-2.9.13-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0a324e529d drupal7-7.72-1.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f9a03b mbedtls-2.7.17-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-25e525a9ca seamonkey-2.53.4-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-918ad695f6 proftpd-1.3.5e-10.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d968abb383 golang-1.15.2-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing IP2Location-8.0.9-9.20200916git6e49424.el7 mock-2.6-1.el7 mock-core-configs-33-1.el7 nginx-1.16.1-2.el7 perl-URI-cpan-1.007-3.el7 python-ldap3-2.8.1-1.el7 Details about builds: IP2Location-8.0.9-9.20200916git6e49424.el7 (FEDORA-EPEL-2020-f4d76a2061) C library for mapping IP address to geolocation information Update Information: subpackage data-sample: add suffix "SAMPLE" to included BIN files, fix file permissions add patch to sync with upstream ChangeLog: mock-2.6-1.el7 (FEDORA-EPEL-2020-0996fb7a3c) Builds packages inside chroots Update Information: mock - because of the mock-filesystem change, we need to enforce upgrade of the old mock-core-configs package - set the DNF user_agent in dnf.conf (msu...@redhat.com) - introduce mock-filesystem subpackage (msu...@redhat.com) - add showrc plugin to record the output of rpm --showrc (riehe...@fnal.gov) - document which packages we need in buildroot (msu...@redhat.com) - macros without leading '%' like config_opts['macros']['macroname'] work fine again (issue#605) mock-core-cofnigs - provide the Fedora ELN mock configuration - some adjustments were done for the new mock-filesystem package https://github.com/rpm-software-management/mock/wiki/Release-Notes-2.6 - the --recurse option implies --continue - fix --chain --continue option - fail when --continue/--recurse is used without --chain - fix _copy_config() for broken symlinks in dst= (rhbz#1878924) - auto-download the source RPMs from web with --rebuild - handle exceptions from command_parse() method - fail verbosely for --chain & --resultdir combination - allow using -a|--addrepo with /absolute/path/argument - add support for -a/--addrepo in normal --rebuild mode - use systemd-nspawn --resolv-conf=off - create /etc/localtime as symlink even with isolation=simple (msu...@redhat.com) - dump the reason for particular package build fail in --chain - raise PkgError when the source RPM can not be installed ChangeLog: * Tue Sep 15 2020 Pavel Raiskup 2.6-1 - the --recurse option implies --continue - fix --chain --continue option - fail when --continue/--recurse is used without --chain - fix _copy_config() for broken symlinks in dst= (rhbz#1878924) - auto-download the source RPMs from web with --rebuild - handle exceptions from command_parse() method - fail verbosely for --chain & --resultdir combination - allow using -a|--addrepo with /absolute/path/argument - add support for -a/--addrepo in normal --rebuild mode - use systemd-nspawn --resolv-conf=off - create /etc/localtime as symlink even with isolation=simple (msu...@redhat.com) - dump the reason for particular package build fail in --chain - raise PkgError when the source RPM can not be installed * Thu Sep 3 2020 Pavel Raiskup 2.5-2 - because of the mock-filesystem change, we need to enforce upgrade of the old mock-core-configs package * Thu Sep 3 2020 Pavel Raiskup 2.5-1 - set the DNF user_agent in dnf.conf (msu...@redhat.com) - introduce mock-filesystem subpackage (msu...@redhat.com) - add showrc plugin to record the output of rpm --showrc (riehe...@fnal.gov) - document which packages we need in buildroot (msu...@redhat.com) - macros without leading '%' like config_opts['macros']['macroname'] work fine again (issue#605)
