[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c1577dae55 singularity-3.1.1-1.1.el6 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2f5f6c5ba9 libmediainfo-19.04-1.el6 mediainfo-19.04-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing drupal7-7.67-1.el6 munin-2.0.49-1.el6 php-theseer-autoload-1.25.6-1.el6 Details about builds: drupal7-7.67-1.el6 (FEDORA-EPEL-2019-612bab5fc3) An open-source content-management platform Update Information: - https://www.drupal.org/project/drupal/releases/7.67 - [SA- CORE-2019-007](https://www.drupal.org/SA-CORE-2019-007) ([CVE-2019-11831](https://nvd.nist.gov/vuln/detail/CVE-2019-11831)) ChangeLog: * Wed May 15 2019 Shawn Iwinski - 7.67-1 - Update to 7.67 (RHBZ #1707958, #1708649, #1708652, #1708653) - https://www.drupal.org/SA-CORE-2019-007 (CVE-2019-11831) References: [ 1 ] Bug #1707958 - drupal7-7.67 is available https://bugzilla.redhat.com/show_bug.cgi?id=1707958 munin-2.0.49-1.el6 (FEDORA-EPEL-2019-2ea97da4a2) Network-wide resource monitoring tool Update Information: Upstream update for 2.0.49. Includes bugfixes for example for graph zoom urls and TLS config. ChangeLog: * Thu May 16 2019 Kim B. Heino - 2.0.49-1 - Upgrade to 2.0.49 * Mon Mar 18 2019 Kim B. Heino - 2.0.45-2 - Drop munin-plugins-java subpackage References: [ 1 ] Bug #1710596 - TLS config is not configurable per-node https://bugzilla.redhat.com/show_bug.cgi?id=1710596 php-theseer-autoload-1.25.6-1.el6 (FEDORA-EPEL-2019-953ff25e9c) A tool and library to generate autoload code Update Information: **Release 1.25.6** * Fix: Add `lib-` prefixed dependencies in composer.json to ignore list ChangeLog: * Thu May 16 2019 Remi Collet - 1.25.6-1 - update to 1.25.6 ___ 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 275 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 83 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f8311ec8a2 tor-0.3.5.8-1.el7 51 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294 cinnamon-3.6.7-5.el7 43 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50a6a1ddfd afflib-3.7.18-2.el7 17 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 14 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-04c7455f6a singularity-3.1.1-1.1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0d44655ca3 mediaconch-18.03.2-7.el7 libmediainfo-19.04-1.el7 mediainfo-19.04-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing dist-git-1.11-1.el7 drupal7-7.67-1.el7 libuv-1.29.0-1.el7 munin-2.0.49-1.el7 php-theseer-autoload-1.25.6-1.el7 rust-1.34.2-1.el7 Details about builds: dist-git-1.11-1.el7 (FEDORA-EPEL-2019-48c9e4991f) Package source version control system Update Information: - remove python3-configparser require - move scripts to bindir - python3 support - fix for empty webhook dir ChangeLog: * Tue Apr 30 2019 clime 1.11-1 - remove python3-configparser require - move scripts to bindir * Mon Mar 11 2019 clime 1.10-1 - python3 support - fix post-receive hook in case post.receive.d is empty drupal7-7.67-1.el7 (FEDORA-EPEL-2019-1605b73a09) An open-source content-management platform Update Information: - https://www.drupal.org/project/drupal/releases/7.67 - [SA- CORE-2019-007](https://www.drupal.org/SA-CORE-2019-007) ([CVE-2019-11831](https://nvd.nist.gov/vuln/detail/CVE-2019-11831)) ChangeLog: * Wed May 15 2019 Shawn Iwinski - 7.67-1 - Update to 7.67 (RHBZ #1707958, #1708649, #1708652, #1708653) - https://www.drupal.org/SA-CORE-2019-007 (CVE-2019-11831) References: [ 1 ] Bug #1707958 - drupal7-7.67 is available https://bugzilla.redhat.com/show_bug.cgi?id=1707958 libuv-1.29.0-1.el7 (FEDORA-EPEL-2019-69f42e0b0d) Platform layer for node.js Update Information: Update to libuv 1.29.0 Fix regression causing segmentation faults ChangeLog: * Wed May 15 2019 Stephen Gallagher - 1.29.0-1 - Update to 1.29.0 - Drop upstreamed patch * Fri May 3 2019 Stephen Gallagher - 1.28.0-2 - Fix regression in uv_fs_poll_stop() (BZ 1703935) * Tue Apr 23 2019 Stephen Gallagher - 1.28.0-1 - Update to libuv 1.28.0 - https://github.com/libuv/libuv/blob/v1.28.0/ChangeLog References: [ 1 ] Bug #1700033 - libuv-1.29.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=1700033 [ 2 ] Bug #1703935 - assertion failure since 1.27.0 https://bugzilla.redhat.com/show_bug.cgi?id=1703935 munin-2.0.49-1.el7 (FEDORA-EPEL-2019-4067ba7c92) Network-wide resource monitoring tool Update Information: Upstream update for 2.0.49. Includes bugfixes for example for graph zoom urls and TLS config. ChangeLog: * Thu May 16 2019 Kim B. Heino - 2.0.49-1 - Upgrade to 2.0.49 * Mon Mar 18 2019 Kim B. Heino - 2.0.45-2 - Drop munin-plugins-java subpackage References: [ 1 ] Bug #1710596 - TLS config is not configurable per-node https://bugzilla.redhat.com/show_bug.cgi?id=1710596 ==
[EPEL-devel] Re: Project plans for EL-8 (2019-05-15 good til 2019-05-22)
Once upon a time, Stephen John Smoogen said: > RHEL-8 was built with various packages which are not shipped in > BaseOS/AppStream/CRB. Some like screen are in the buildroot for the > packages which depend on them but were decided not to be shipped. Huh, that's... weird. As someone that's been using screen for, hmm, longer than Red Hat's been in business I think... that's annoying. I guess the CentOS side would be the more appropriate place to ask, but would it be practical to gather up these packages and make a CentOS "module" of them? Sorry if that doesn't make sense (like I said, still trying to get my head around modularity). -- Chris Adams ___ 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: Project plans for EL-8 (2019-05-15 good til 2019-05-22)
On Thu, 16 May 2019 at 09:59, Chris Adams wrote: > So, I don't have a handle on the whole modularity thing... still trying > to understand what's what with that. But this caught my eye in your > "Open Questions": > > - Some normally leaf packages like screen are inside of the Red Hat > hidden buildroot package set. Having them built in EPEL is likely to > cause conflicts on user systems and divergence with RHEL. EPEL > maintains agreed upon policies for these cases so using the repo > doesn’t cause pain for RHEL customers or users. > > What does that actually mean? I'm a consumer of CentOS rather than RHEL > these days, so I haven't really dug into version 8 yet. I do use screen > a lot, so what does "inside of the Red Hat hidden buildroot package set" > mean for me? > > RHEL-8 was built with various packages which are not shipped in BaseOS/AppStream/CRB. Some like screen are in the buildroot for the packages which depend on them but were decided not to be shipped. Thus they are hidden buildroot set. They were however branched to CentOS git repository. While building a newer version of screen and putting it in EPEL might not break anything, other packages might cause problems which we don't have the resources to track down and debug. So I would like to not have EPEL rebuild any package which was branched to CentOS EL-8. I will clarify the document. > -- > Chris Adams > ___ > 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 > -- Stephen J Smoogen. ___ 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: Project plans for EL-8 (2019-05-15 good til 2019-05-22)
On Thu, 16 May 2019 at 09:48, Dan Horák wrote: > On Wed, 15 May 2019 18:06:21 -0400 > Stephen John Smoogen wrote: > > > In trying to get resources allocated, I have been working on the > > project plans for 8. The original one was at > > https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8 > > > > As of today an updated one is at > > > > https://smooge.fedorapeople.org/EPEL-8/ > > is there a plan to start EPEL-8 with all arches supported by RHEL-8? So > s390x will be also included? We never bootstrapped EPEL-7 for s390x, but > it wasn't a blocker because there is a rebuild available from the ClefOS > people (they do a CentOS rebuild for s390x). We are registering > questions about availability of EPEL for s390x quite regularly. > > It will depend on the resources available for s390x. Currently all s390x builds are done on a system shared with other builds which is severely overloaded. Adding more build targets needs to be weighed with 'can we do it without breaking our house of cards anymore'. If more resources are available or other changes, it will be seriously looked at. [I have downloaded RHEL-8 s390x just in case.] > > Thanks > > Dan > ___ > 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 > -- Stephen J Smoogen. ___ 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: Project plans for EL-8 (2019-05-15 good til 2019-05-22)
So, I don't have a handle on the whole modularity thing... still trying to understand what's what with that. But this caught my eye in your "Open Questions": - Some normally leaf packages like screen are inside of the Red Hat hidden buildroot package set. Having them built in EPEL is likely to cause conflicts on user systems and divergence with RHEL. EPEL maintains agreed upon policies for these cases so using the repo doesn’t cause pain for RHEL customers or users. What does that actually mean? I'm a consumer of CentOS rather than RHEL these days, so I haven't really dug into version 8 yet. I do use screen a lot, so what does "inside of the Red Hat hidden buildroot package set" mean for me? -- Chris Adams ___ 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: Project plans for EL-8 (2019-05-15 good til 2019-05-22)
On Wed, 15 May 2019 18:06:21 -0400 Stephen John Smoogen wrote: > In trying to get resources allocated, I have been working on the > project plans for 8. The original one was at > https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8 > > As of today an updated one is at > > https://smooge.fedorapeople.org/EPEL-8/ is there a plan to start EPEL-8 with all arches supported by RHEL-8? So s390x will be also included? We never bootstrapped EPEL-7 for s390x, but it wasn't a blocker because there is a rebuild available from the ClefOS people (they do a CentOS rebuild for s390x). We are registering questions about availability of EPEL for s390x quite regularly. Thanks Dan ___ 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: Project plans for EL-8 (2019-05-15 good til 2019-05-22)
NOTICE: I have been informed that various parts of the document have major errors. I will be updating and fixing today. Problems include the mentioning various javapackages which were shipped and not spelling out that one of the differences between internal and external is usra-major On Wed, 15 May 2019 at 18:06, Stephen John Smoogen wrote: > > In trying to get resources allocated, I have been working on the project > plans for 8. The original one was at > https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8 > > As of today an updated one is at > > https://smooge.fedorapeople.org/EPEL-8/ > > which I will translate to wiki for better editing this weekend. However > the core items I am currently working on > > 1. https://smooge.fedorapeople.org/EPEL-8/EPEL-8-known-package-list.txt > contains > a list of packages I know we can't rebuild (because they will be in > CentOS/RHEL-8 and a list of packages I know will build with our first > attempt at EPEL-8 > > 2. I am currently working on patches for > https://github.com/puiterwijk/grobisplitter so that I can get it to work > with how Red Hat publishes its packages. I am also working on it just > breaking out default modules. > > 3. I have discovered that modules which have no default channel should not > be used to build non-modular packages against. There are 6 modules set up > this way > ( 389-ds, libselinux-python, mod_auth_openidc, parfait, pki-core, pki-deps > ) and so the packages in them will not be available to build against. Even > after we have some ursa-* solution in place, packages requiring them must > be part of a module. > > > > > > -- > Stephen J Smoogen. > > -- Stephen J Smoogen. ___ 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
