[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-612bab5fc3 drupal7-7.67-1.el6 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5ff064965f drupal7-entity-1.9-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50e0fd4815 drupal7-ds-2.16-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fe7c636c57 drupal7-uuid-1.2-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6326ff7745 drupal7-xmlsitemap-2.6-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-65bad7ac43 drupal7-context-3.10-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5621f2527a drupal7-path_breadcrumbs-3.4-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1af316b5db drupal7-module_filter-2.2-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e90e3284bc drupal7-views-3.23-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing mozilla-https-everywhere-2019.5.13-1.el6 singularity-3.2.1-1.el6 spectre-meltdown-checker-0.42-1.el6 Details about builds: mozilla-https-everywhere-2019.5.13-1.el6 (FEDORA-EPEL-2019-84fd95bff3) HTTPS enforcement extension for Mozilla Firefox Update Information: - UI and functionality patches for stable rules - Translations string fixes - Minor npm updates for HSTS pruning ChangeLog: * Tue May 21 2019 Russell Golden - 2019.5.13-1 - UI and functionality patches for stable rules - Translations string fixes - Minor npm updates for HSTS pruning References: [ 1 ] Bug #1709619 - mozilla-https-everywhere-2019.5.13 is available https://bugzilla.redhat.com/show_bug.cgi?id=1709619 singularity-3.2.1-1.el6 (FEDORA-EPEL-2019-9a2a974d76) Application and environment virtualization Update Information: Update to 3.2.1 ChangeLog: * Wed May 29 2019 Dave Dykstra - 3.2.1-1 - Update to upstream 3.2.1-1 * Mon May 20 2019 Dave Dykstra - 3.2.0-1.1 - Add PR #3419 * Mon May 20 2019 Dave Dykstra - 3.2.0-1 - Update to upstream 3.2.0-1 References: [ 1 ] Bug #1696499 - singularity-3.2.1-rc1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1696499 spectre-meltdown-checker-0.42-1.el6 (FEDORA-EPEL-2019-2c02a8e195) Spectre & Meltdown vulnerability/mitigation checker for Linux Update Information: Update to 0.42 * Feature: add FreeBSD MDS mitigation detection * Feature: add mocking functionality to help debugging, dump data to mock the behavior of your CPU with `--dump-mock-data` * Fix: AMD, ARM and CAVIUM are not vulnerable to MDS * Fix: RDCL_NO bit wasn't taking precedence for L1TF check on some newer Intel CPUs * Fix: The MDS_NO bit on newer Intel CPUs is now recognized and used * Fix: remove libvirtd from hypervisor detection to avoid false positives ([#278](https://github.com/speed47/spectre-meltdown-checker/issues/278)) * Fix: under BSD, the data returned when reading MSR was incorrectly formatted * Misc: update builtin MCEdb from v110 to v111 ChangeLog: * Thu May 30 2019 Reto Gantenbein - 0.42-1 - Update to 0.42 ___ 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://getfedora.org/code-of-conduct.html 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 289 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 97 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f8311ec8a2 tor-0.3.5.8-1.el7 64 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294 cinnamon-3.6.7-5.el7 57 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50a6a1ddfd afflib-3.7.18-2.el7 30 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 28 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1605b73a09 drupal7-7.67-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-87fa8d93b6 drupal7-entity-1.9-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b909a6e178 sleuthkit-4.6.6-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9cab93353c drupal7-ds-2.16-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2c1ec539fd drupal7-uuid-1.2-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f614c9a4bc drupal7-xmlsitemap-2.6-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8278894e4d drupal7-context-3.10-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-de5e3216ff drupal7-path_breadcrumbs-3.4-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-748b40598c drupal7-module_filter-2.2-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-53f9189a5e drupal7-views-3.23-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-043371cfab rust-1.35.0-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fc63c75ab1 hostapd-2.8-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing isync-1.3.1-1.el7 mozilla-https-everywhere-2019.5.13-1.el7 python-pyngus-2.3.0-1.el7 singularity-3.2.1-1.el7 spectre-meltdown-checker-0.42-1.el7 xorgxrdp-0.2.10-1.el7 Details about builds: isync-1.3.1-1.el7 (FEDORA-EPEL-2019-6fc3c83374) A tool to synchronize IMAP4 and Maildir mailboxes Update Information: Support for SNI (rhbz#1632958) ChangeLog: * Wed May 29 2019 Fabian Affolter - 1.3.1-1 - Support for SNI (rhbz#1632958) - Update to new upstream version 1.3.1 (rhbz#1714679) * Fri Feb 1 2019 Fedora Release Engineering - 1.3.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Fri Jul 13 2018 Fedora Release Engineering - 1.3.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Wed Feb 7 2018 Fedora Release Engineering - 1.3.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Sun Jan 7 2018 Michael J Gruber - 1.3.0-1 - Update to new upstream version 1.3.0 (rhbz#1497574) * Sun Oct 1 2017 Fabian Affolter - 1.2.3-1 - Update to new upstream version 1.2.3 (rhbz#1497526) * Wed Aug 2 2017 Fedora Release Engineering - 1.2.1-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild * Wed Jul 26 2017 Fedora Release Engineering - 1.2.1-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild * Sat Mar 25 2017 Fabian Affolter - 1.2.1-4 - Fix FTBFS (rhbz#1423747) * Fri Feb 10 2017 Fedora Release Engineering - 1.2.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild * Thu Feb 4 2016 Fedora Release Engineering - 1.2.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild * Tue Nov 10 2015 Fabian Affolter - 1.2.1-1 - Update to new upstream version 1.2.0 (rhbz#1279883) * Wed Jun 17 2015 Fedora Release Engineering - 1.2.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild References: [ 1 ] Bug #1632958 - isync fails to sync to gmail with TLS and SNI https://bugzilla.redhat.com/show_bug.cgi?id=1632958 [ 2 ] Bug #1714679 - isync-1.3.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1714679 mozilla-https-everywhere-2019.5.13-1.el7 (FEDORA-EPEL-2019-bd51fcdac7) HTTPS enforcement extension for Mozilla Firefox Update Information: - UI and functionality patches for stable rules - Translations string fixes - Minor npm updates for HSTS pruning
[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019, at 6:57 PM, Stephen Gallagher wrote: > On Thu, May 30, 2019 at 4:25 PM James Cassell > wrote: > > > > > > > > > Historical composes are intended to be frozen and unchanging, but this > > > > approach leaves open the possibility of tagging other builds into > > > > epel8-8.Y and regenerating the compose if the need arises. It will > > > > need to be communicated that these repositories will not receive > > > > updates and are intended to be only a snapshot of the past that is > > > > known to work with a particular RHEL 8.Y base. > > > > > > > This will be very helpful, especially if the epel-release .repo file honors > > the $releasever variable. > > > Can you explain what behavior you see here? I can't really parse from > your reply what you think/expect to have happen here, and I'd like to > make sure we address it properly. The use case is preventing updates past a minor version without explicit administrator action. We're able to do this by forcing the $releasever yum variable to be 7.50 (for RHEL) or 7.5.1804 (for CentOS). It would be convenient to keep this approach working by using the yum var in the repo file, with requisite symlinks in place on the mirrors. The repo file as is today would likely work for this purpose (but I don't have it in front of me to verify.) V/r, James Cassell ___ 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://getfedora.org/code-of-conduct.html 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 Branch Strategy
On Thu, May 30, 2019 at 4:25 PM James Cassell wrote: > > > > > > Historical composes are intended to be frozen and unchanging, but this > > > approach leaves open the possibility of tagging other builds into > > > epel8-8.Y and regenerating the compose if the need arises. It will > > > need to be communicated that these repositories will not receive > > > updates and are intended to be only a snapshot of the past that is > > > known to work with a particular RHEL 8.Y base. > > > > This will be very helpful, especially if the epel-release .repo file honors > the $releasever variable. Can you explain what behavior you see here? I can't really parse from your reply what you think/expect to have happen here, and I'd like to make sure we address it properly. ___ 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://getfedora.org/code-of-conduct.html 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 Branch Strategy
On Thu, May 30, 2019 at 4:02 PM Troy Dawson wrote: > > On Thu, May 30, 2019 at 12:18 PM Kevin Fenzi wrote: > > Also might there be people who want to always keep something in rawhide > > and never push it to the stable stream? Or do we want to encourage only > > things destined for the next minor change land in epel8-rawhide? > > > > Yes. We need to keep that in consideration. > When cleaning up the -testing branches of EPEL6 and EPEL7 we found > there were people who had versions in -testing that they never > intended to push to stable. > Once EPEL8/7 has modularity, there will be an official way to do that, > but until that happens, we need to assume that some people will use > rawhide as a way to have a second version of their package. > Right, I think Troy has the pulse of it. I think the current design is compatible with that, though. I see the following common cases from most to least common: 1) Leave package.cfg in epel8, build only there -> epel8 repo and epel8-rawhide repo 2) Remove package.cfg in epel 8. Build stable in epel8 -> epel8 repo. Build major release planned for an upcoming (not necessarily next...) X.Y release in Rawhide -> epel8-rawhide repo. 3) Remove package.cfg in epel 8. Build stable in epel8 -> epel8 repo. Build rolling release in epel8-rawhide of the latest upstream bits, not necessarily ever planning to move it into stable -> epel8-rawhide repo. Case 3 I think will slowly disappear once we enable (and simplify creation of) modules in EPEL 8, since they'll be able to just provide a non-default stream. ___ 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://getfedora.org/code-of-conduct.html 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 Branch Strategy
On Thu, May 30, 2019 at 3:18 PM Kevin Fenzi wrote: > > > As discussed in the EPEL SIG meeting yesterday, I've written up my > > thoughts on how to handle epel8 branches. > > TLDR: I like it. ;) > > > # Considerations > > * The process must be simple for a Fedora packager to adapt to > > * It must be possible to stage big (possibly backwards-incompatible) changes > > * Where possible, the packager experience should be the same as EPEL 7 > > > > # Proposal > > There will be two branches created for EPEL 8 in dist-git for each > > component: > > > > ## epel8: > > Most packagers will do their work here. This branch will be set up by > > default with a package.cfg file containing: > > ``` > > [koji] > > targets = epel8 epel8-rawhide > > ``` > > Recent fedpkg supports using package.cfg files in the root of the > > dist-git repository to trigger builds for multiple releases at the > > same time. > > > > > > ## epel8-rawhide: > > This branch will be left alone until and unless the packager decides > > that they want to stage a major (possibly incompatible) change for the > > next RHEL 8.Y minor release. At that time, they will need to remove > > the package.cfg file from the epel8 branch and manually merge the > > proposed changes desired into the epel8-rawhide branch and build > > there. > > Also might there be people who want to always keep something in rawhide > and never push it to the stable stream? Or do we want to encourage only > things destined for the next minor change land in epel8-rawhide? > > > The package.cfg setup will mean that running `fedpkg build` in the > > epel8 branch will cause it to be built both for the > > epel8-rawhide-candidate and epel8-stable-candidate tags in Koji. > > How about we just call the stable tag 'epel8-candidate' ? > Sure, that's actually a vestige of my first draft of this, which I rewrote which had "epel8" as the combined repo and "epel-stable" as the branched-off one for when you wanted to lock things. After consideration, I realized that packagers acting like EPEL 7 (generally only doing the stable, compatible release) would be the common case and I reversed that to the version you see here. I left the tag names specific to eliminate ambiguity, but that's entirely a cosmetic choice and as long as they're unique and consistent, I don't care what they are, particularly. > > Packages built for epel8-rawhide-candidate will behave similarly to > > Rawhide in Fedora and be signed and tagged into an epel8-rawhide > > compose. > > > > Packages built for epel8-stable-candidate will behave similarly to > > Fedora stable releases and be required to go through Bodhi to get to > > an epel8 compose (and associated epel8-testing compose). > > > > For packages operating in the default configuration, the packager will > > need to build in the epel8 branch and then submit the built package to > > Bodhi, just as they would have done for EPEL 7. The side-effect here > > is that the build will also produce a build that goes to the > > epel8-rawhide repository without Bodhi intervention. > > Or we could at some point hook in gating, just like fedora rawhide. > Sorry, just had a dream of a pleasant future. ;) > I suppose I should have phrased that differently, or just said "processed in the same manner as Fedora Rawhide". But yes, if we can get these properly gated, that's also great. > > > > When the time comes where an incompatible change needs to land, they > > must be coordinated to land on an approved schedule. The exact > > mechanism of scheduling and coordinating this is out of scope for this > > document and will be decided on by the EPEL Steering Committee. > > Yeah, but we should probibly try and figure it out. > I was worried that the logistics of this would derail the conversation about the branching, so I tried to preempt that. The timing is something that will be a policy, the rest of this proposal is about technical design. > I guess there is: > A. Right after the new minor release comes out > B. Right after the new minor release comes out for CentOS > C. Some arbitrary time after the new minor release comes out. > No comment at this time :) > > > > At this time, the packager must remove the package.cfg file from the > > epel8 branch and package the new version in the epel8-rawhide branch. > > With the package.cfg file removed from the epel8 branch, builds in > > that branch will be built only for the epel8-stable-candidate tag. As > > before, composes including these builds will be managed by Bodhi > > updates. Building from the epel8 branch will therefore not be > > automatically built for epel8-rawhide any longer. > > > > Builds intended for the epel8-rawhide repository will need to be built > > instead from the epel8-rawhide branch, which will build against the > > epel8-rawhide-candidate target, which will then be signed and pushed > > to the epel8-rawhide repository like before. > > > > Once the package is approved to be promoted from the epel8-rawhide > >
[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019, at 3:18 PM, Kevin Fenzi wrote: > > As discussed in the EPEL SIG meeting yesterday, I've written up my > > thoughts on how to handle epel8 branches. > [...] > > > > When the time comes where an incompatible change needs to land, they > > must be coordinated to land on an approved schedule. The exact > > mechanism of scheduling and coordinating this is out of scope for this > > document and will be decided on by the EPEL Steering Committee. > > Yeah, but we should probibly try and figure it out. > > I guess there is: > A. Right after the new minor release comes out > B. Right after the new minor release comes out for CentOS > C. Some arbitrary time after the new minor release comes out. > I'd be in favor of B. [...] > > # Historical Composes > > Since major changes may occur at RHEL 8.Y releases, we want to support > > allowing our users to lock onto a repository that matches that > > release. For this, we will generate historical composes, which will > > match the stable package set of the prior minor release once the new > > minor release comes out. > > > > At 00:00 UTC of the day following a new RHEL 8.Y release, an updated > > epel-release package will be pushed, updating the %dist tag to the new > > .epel8_Y value. All new builds will thus have the new dist tag. A > > script will be run at this time to apply a new Koji tag (epel8-8.Y) to > > the latest build of a package with one of the following tags: [ > > epel8-stable, epel8-stable-pending ]. A compose of the epel8.Y > > repository will be created at this time from all packages currently > > tagged as epel8-8.Y. > > So, we will also have to unpush/obsolete/close all pending bodhi updates > right? Since things will need rebuilding with the new dist tag for the > new minor. I'd say just cancel any karma, reset the timer, then let them go out as-is once/if they again pass the bodhi process. > > > > Historical composes are intended to be frozen and unchanging, but this > > approach leaves open the possibility of tagging other builds into > > epel8-8.Y and regenerating the compose if the need arises. It will > > need to be communicated that these repositories will not receive > > updates and are intended to be only a snapshot of the past that is > > known to work with a particular RHEL 8.Y base. > This will be very helpful, especially if the epel-release .repo file honors the $releasever variable. V/r, James Cassell ___ 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://getfedora.org/code-of-conduct.html 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 Branch Strategy
On Thu, May 30, 2019 at 12:18 PM Kevin Fenzi wrote: > > > As discussed in the EPEL SIG meeting yesterday, I've written up my > > thoughts on how to handle epel8 branches. > > TLDR: I like it. ;) > > > # Considerations > > * The process must be simple for a Fedora packager to adapt to > > * It must be possible to stage big (possibly backwards-incompatible) changes > > * Where possible, the packager experience should be the same as EPEL 7 > > > > # Proposal > > There will be two branches created for EPEL 8 in dist-git for each > > component: > > > > ## epel8: > > Most packagers will do their work here. This branch will be set up by > > default with a package.cfg file containing: > > ``` > > [koji] > > targets = epel8 epel8-rawhide > > ``` > > Recent fedpkg supports using package.cfg files in the root of the > > dist-git repository to trigger builds for multiple releases at the > > same time. > > > > > > ## epel8-rawhide: > > This branch will be left alone until and unless the packager decides > > that they want to stage a major (possibly incompatible) change for the > > next RHEL 8.Y minor release. At that time, they will need to remove > > the package.cfg file from the epel8 branch and manually merge the > > proposed changes desired into the epel8-rawhide branch and build > > there. > > Also might there be people who want to always keep something in rawhide > and never push it to the stable stream? Or do we want to encourage only > things destined for the next minor change land in epel8-rawhide? > Yes. We need to keep that in consideration. When cleaning up the -testing branches of EPEL6 and EPEL7 we found there were people who had versions in -testing that they never intended to push to stable. Once EPEL8/7 has modularity, there will be an official way to do that, but until that happens, we need to assume that some people will use rawhide as a way to have a second version of their package. > > The package.cfg setup will mean that running `fedpkg build` in the > > epel8 branch will cause it to be built both for the > > epel8-rawhide-candidate and epel8-stable-candidate tags in Koji. > > How about we just call the stable tag 'epel8-candidate' ? > > > Packages built for epel8-rawhide-candidate will behave similarly to > > Rawhide in Fedora and be signed and tagged into an epel8-rawhide > > compose. > > > > Packages built for epel8-stable-candidate will behave similarly to > > Fedora stable releases and be required to go through Bodhi to get to > > an epel8 compose (and associated epel8-testing compose). > > > > For packages operating in the default configuration, the packager will > > need to build in the epel8 branch and then submit the built package to > > Bodhi, just as they would have done for EPEL 7. The side-effect here > > is that the build will also produce a build that goes to the > > epel8-rawhide repository without Bodhi intervention. > > Or we could at some point hook in gating, just like fedora rawhide. > Sorry, just had a dream of a pleasant future. ;) > > > > > When the time comes where an incompatible change needs to land, they > > must be coordinated to land on an approved schedule. The exact > > mechanism of scheduling and coordinating this is out of scope for this > > document and will be decided on by the EPEL Steering Committee. > > Yeah, but we should probibly try and figure it out. > > I guess there is: > A. Right after the new minor release comes out > B. Right after the new minor release comes out for CentOS > C. Some arbitrary time after the new minor release comes out. > > > > > At this time, the packager must remove the package.cfg file from the > > epel8 branch and package the new version in the epel8-rawhide branch. > > With the package.cfg file removed from the epel8 branch, builds in > > that branch will be built only for the epel8-stable-candidate tag. As > > before, composes including these builds will be managed by Bodhi > > updates. Building from the epel8 branch will therefore not be > > automatically built for epel8-rawhide any longer. > > > > Builds intended for the epel8-rawhide repository will need to be built > > instead from the epel8-rawhide branch, which will build against the > > epel8-rawhide-candidate target, which will then be signed and pushed > > to the epel8-rawhide repository like before. > > > > Once the package is approved to be promoted from the epel8-rawhide > > compose to the stable compose, the package.cfg should be recreated in > > the epel8 branch (this can be automated to make it easier) and a new > > build will be made in the epel8 branch that will produce builds in the > > epel8-stable-candidate and epel8-rawhide-candidate tags, with the > > former then being submitted to Bodhi. This new build must naturally > > have a higher ENVR to preserve the upgrade path. > > > > ## %dist tag > > Packages built against epel8-rawhide-candidate will be built with a > > %dist tag of .epel8_rawhide > > Packages built against epel8-rawhide-candidate will be
[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy
On 30. 05. 19 20:21, Stephen Gallagher wrote: ## epel8-rawhide: This branch will be left alone until and unless the packager decides that they want to stage a major (possibly incompatible) change for the next RHEL 8.Y minor release. At that time, they will need to remove the package.cfg file from the epel8 branch and manually merge the proposed changes desired into the epel8-rawhide branch and build there. Just a small consideration here: Can this thing not be called Rawhide? Rawhide is Fedora. I'd like to keep that clear, so when we talk about rawhide in various places, we don't have to say: Fedora Rawhide (although we often do). Imagine this conversation: A: I want to do a major cleanup of %scripts in Fedora. B: But what about EPEL? A: I'll do it in Rawhide only. Having an EPEL Rawhide makes the last statement ambiguous. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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://getfedora.org/code-of-conduct.html 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 Branch Strategy
> As discussed in the EPEL SIG meeting yesterday, I've written up my > thoughts on how to handle epel8 branches. TLDR: I like it. ;) > # Considerations > * The process must be simple for a Fedora packager to adapt to > * It must be possible to stage big (possibly backwards-incompatible) changes > * Where possible, the packager experience should be the same as EPEL 7 > > # Proposal > There will be two branches created for EPEL 8 in dist-git for each component: > > ## epel8: > Most packagers will do their work here. This branch will be set up by > default with a package.cfg file containing: > ``` > [koji] > targets = epel8 epel8-rawhide > ``` > Recent fedpkg supports using package.cfg files in the root of the > dist-git repository to trigger builds for multiple releases at the > same time. > > > ## epel8-rawhide: > This branch will be left alone until and unless the packager decides > that they want to stage a major (possibly incompatible) change for the > next RHEL 8.Y minor release. At that time, they will need to remove > the package.cfg file from the epel8 branch and manually merge the > proposed changes desired into the epel8-rawhide branch and build > there. Also might there be people who want to always keep something in rawhide and never push it to the stable stream? Or do we want to encourage only things destined for the next minor change land in epel8-rawhide? > The package.cfg setup will mean that running `fedpkg build` in the > epel8 branch will cause it to be built both for the > epel8-rawhide-candidate and epel8-stable-candidate tags in Koji. How about we just call the stable tag 'epel8-candidate' ? > Packages built for epel8-rawhide-candidate will behave similarly to > Rawhide in Fedora and be signed and tagged into an epel8-rawhide > compose. > > Packages built for epel8-stable-candidate will behave similarly to > Fedora stable releases and be required to go through Bodhi to get to > an epel8 compose (and associated epel8-testing compose). > > For packages operating in the default configuration, the packager will > need to build in the epel8 branch and then submit the built package to > Bodhi, just as they would have done for EPEL 7. The side-effect here > is that the build will also produce a build that goes to the > epel8-rawhide repository without Bodhi intervention. Or we could at some point hook in gating, just like fedora rawhide. Sorry, just had a dream of a pleasant future. ;) > > When the time comes where an incompatible change needs to land, they > must be coordinated to land on an approved schedule. The exact > mechanism of scheduling and coordinating this is out of scope for this > document and will be decided on by the EPEL Steering Committee. Yeah, but we should probibly try and figure it out. I guess there is: A. Right after the new minor release comes out B. Right after the new minor release comes out for CentOS C. Some arbitrary time after the new minor release comes out. > > At this time, the packager must remove the package.cfg file from the > epel8 branch and package the new version in the epel8-rawhide branch. > With the package.cfg file removed from the epel8 branch, builds in > that branch will be built only for the epel8-stable-candidate tag. As > before, composes including these builds will be managed by Bodhi > updates. Building from the epel8 branch will therefore not be > automatically built for epel8-rawhide any longer. > > Builds intended for the epel8-rawhide repository will need to be built > instead from the epel8-rawhide branch, which will build against the > epel8-rawhide-candidate target, which will then be signed and pushed > to the epel8-rawhide repository like before. > > Once the package is approved to be promoted from the epel8-rawhide > compose to the stable compose, the package.cfg should be recreated in > the epel8 branch (this can be automated to make it easier) and a new > build will be made in the epel8 branch that will produce builds in the > epel8-stable-candidate and epel8-rawhide-candidate tags, with the > former then being submitted to Bodhi. This new build must naturally > have a higher ENVR to preserve the upgrade path. > > ## %dist tag > Packages built against epel8-rawhide-candidate will be built with a > %dist tag of .epel8_rawhide > Packages built against epel8-rawhide-candidate will be built with a > %dist tag of .epel8_Y where “Y” is the latest stable release of RHEL > 8. > > This dist tag structure ensures that the version of the package in the > stable epel8 repository will win out over the one in the epel8-rawhide > repository if all other aspects of the EVR are the same. (So one would > only pick up a newer version from epel8-rawhide if it was indeed a > higher version number.) It does also mean you have to do another build of anything to get it stable. The rawhide build never goes stable, just a rebuilt version of it does... thats a bit more work, but not too bad. > # Historical Composes > Since major
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 288 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 96 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f8311ec8a2 tor-0.3.5.8-1.el7 64 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294 cinnamon-3.6.7-5.el7 57 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50a6a1ddfd afflib-3.7.18-2.el7 30 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 28 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1605b73a09 drupal7-7.67-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-87fa8d93b6 drupal7-entity-1.9-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b909a6e178 sleuthkit-4.6.6-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9cab93353c drupal7-ds-2.16-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2c1ec539fd drupal7-uuid-1.2-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f614c9a4bc drupal7-xmlsitemap-2.6-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8278894e4d drupal7-context-3.10-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-de5e3216ff drupal7-path_breadcrumbs-3.4-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-748b40598c drupal7-module_filter-2.2-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-53f9189a5e drupal7-views-3.23-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-043371cfab rust-1.35.0-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing certbot-0.34.2-3.el7 hostapd-2.8-1.el7 python-acme-0.34.2-1.el7 python-certbot-apache-0.34.2-1.el7 python-certbot-dns-cloudflare-0.34.2-1.el7 python-certbot-dns-cloudxns-0.34.2-1.el7 python-certbot-dns-digitalocean-0.34.2-1.el7 python-certbot-dns-dnsimple-0.34.2-1.el7 python-certbot-dns-dnsmadeeasy-0.34.2-1.el7 python-certbot-dns-gehirn-0.34.2-1.el7 python-certbot-dns-google-0.34.2-1.el7 python-certbot-dns-linode-0.34.2-1.el7 python-certbot-dns-luadns-0.34.2-1.el7 python-certbot-dns-nsone-0.34.2-1.el7 python-certbot-dns-ovh-0.34.2-1.el7 python-certbot-dns-rfc2136-0.34.2-1.el7 python-certbot-dns-route53-0.34.2-1.el7 python-certbot-dns-sakuracloud-0.34.2-1.el7 python-certbot-nginx-0.34.2-1.el7 python-dns-lexicon-3.2.6-1.el7 Details about builds: certbot-0.34.2-3.el7 (FEDORA-EPEL-2019-389d1dd572) A free, automated certificate authority client Update Information: python-dns-lexicon - Update to 3.2.6 python-acme, certbot, python-certbot-* - Update to 0.34.2 certbot - Run renew timer twice daily with 12-hour random delay - Update `--renew-hook` to `--deploy-hook` ChangeLog: * Tue May 28 2019 Eli Young - 0.34.2-3 - Fix build on Python 2 * Tue May 28 2019 Eli Young - 0.34.2-2 - Update --renew-hook to --deploy-hook (#1665755) * Tue May 28 2019 Eli Young - 0.34.2-1 - Update to 0.34.2 (#1686184) (#1705300) - Run rewew timer twice daily with 12-hour random delay References: [ 1 ] Bug #1685778 - python-dns-lexicon-3.2.6 is available https://bugzilla.redhat.com/show_bug.cgi?id=1685778 [ 2 ] Bug #1686201 - python-acme-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686201 [ 3 ] Bug #1686184 - certbot-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686184 [ 4 ] Bug #1665755 - Replace --renew-hook with --deploy-hook in systemd units https://bugzilla.redhat.com/show_bug.cgi?id=1665755 [ 5 ] Bug #1686185 - python-certbot-apache-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686185 [ 6 ] Bug #1686186 - python-certbot-dns-cloudflare-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686186 [ 7 ] Bug #1686187 - python-certbot-dns-cloudxns-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686187 [ 8 ] Bug #1686188 - python-certbot-dns-digitalocean-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686188 [ 9 ] Bug #1686189 - python-certbot-dns-dnsimple-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686189 [ 10 ] Bug #1686190 - python-certbot-dns-dnsmadeeasy-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686190 [ 11 ] Bug #1686191 - python-certbot-dns-gehirn-0.34.2 is
[EPEL-devel] Proposal: EPEL 8 Branch Strategy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 As discussed in the EPEL SIG meeting yesterday, I've written up my thoughts on how to handle epel8 branches. # Considerations * The process must be simple for a Fedora packager to adapt to * It must be possible to stage big (possibly backwards-incompatible) changes * Where possible, the packager experience should be the same as EPEL 7 # Proposal There will be two branches created for EPEL 8 in dist-git for each component: ## epel8: Most packagers will do their work here. This branch will be set up by default with a package.cfg file containing: ``` [koji] targets = epel8 epel8-rawhide ``` Recent fedpkg supports using package.cfg files in the root of the dist-git repository to trigger builds for multiple releases at the same time. ## epel8-rawhide: This branch will be left alone until and unless the packager decides that they want to stage a major (possibly incompatible) change for the next RHEL 8.Y minor release. At that time, they will need to remove the package.cfg file from the epel8 branch and manually merge the proposed changes desired into the epel8-rawhide branch and build there. The package.cfg setup will mean that running `fedpkg build` in the epel8 branch will cause it to be built both for the epel8-rawhide-candidate and epel8-stable-candidate tags in Koji. Packages built for epel8-rawhide-candidate will behave similarly to Rawhide in Fedora and be signed and tagged into an epel8-rawhide compose. Packages built for epel8-stable-candidate will behave similarly to Fedora stable releases and be required to go through Bodhi to get to an epel8 compose (and associated epel8-testing compose). For packages operating in the default configuration, the packager will need to build in the epel8 branch and then submit the built package to Bodhi, just as they would have done for EPEL 7. The side-effect here is that the build will also produce a build that goes to the epel8-rawhide repository without Bodhi intervention. When the time comes where an incompatible change needs to land, they must be coordinated to land on an approved schedule. The exact mechanism of scheduling and coordinating this is out of scope for this document and will be decided on by the EPEL Steering Committee. At this time, the packager must remove the package.cfg file from the epel8 branch and package the new version in the epel8-rawhide branch. With the package.cfg file removed from the epel8 branch, builds in that branch will be built only for the epel8-stable-candidate tag. As before, composes including these builds will be managed by Bodhi updates. Building from the epel8 branch will therefore not be automatically built for epel8-rawhide any longer. Builds intended for the epel8-rawhide repository will need to be built instead from the epel8-rawhide branch, which will build against the epel8-rawhide-candidate target, which will then be signed and pushed to the epel8-rawhide repository like before. Once the package is approved to be promoted from the epel8-rawhide compose to the stable compose, the package.cfg should be recreated in the epel8 branch (this can be automated to make it easier) and a new build will be made in the epel8 branch that will produce builds in the epel8-stable-candidate and epel8-rawhide-candidate tags, with the former then being submitted to Bodhi. This new build must naturally have a higher ENVR to preserve the upgrade path. ## %dist tag Packages built against epel8-rawhide-candidate will be built with a %dist tag of .epel8_rawhide Packages built against epel8-rawhide-candidate will be built with a %dist tag of .epel8_Y where “Y” is the latest stable release of RHEL 8. This dist tag structure ensures that the version of the package in the stable epel8 repository will win out over the one in the epel8-rawhide repository if all other aspects of the EVR are the same. (So one would only pick up a newer version from epel8-rawhide if it was indeed a higher version number.) # Historical Composes Since major changes may occur at RHEL 8.Y releases, we want to support allowing our users to lock onto a repository that matches that release. For this, we will generate historical composes, which will match the stable package set of the prior minor release once the new minor release comes out. At 00:00 UTC of the day following a new RHEL 8.Y release, an updated epel-release package will be pushed, updating the %dist tag to the new .epel8_Y value. All new builds will thus have the new dist tag. A script will be run at this time to apply a new Koji tag (epel8-8.Y) to the latest build of a package with one of the following tags: [ epel8-stable, epel8-stable-pending ]. A compose of the epel8.Y repository will be created at this time from all packages currently tagged as epel8-8.Y. Historical composes are intended to be frozen and unchanging, but this approach leaves open the possibility of tagging other builds into epel8-8.Y and regenerating the compose if the
