Re: EPEL Notes from .next discussion.
snip lots of stuff Smooge thanks for the write-up. Great points are being brought up by all parties here. I think I'm +1 on a second repo that moves faster and can be incompatible with the right type of announce-list. (maybe even put the uri for that list in the .repo file or something). It also might be acceptable to allow builds against SCL, or bundle libs if we want real speed and end-user convenience. Obviously there's more than a little hand-waving there, so don't consider that anything more than a spitball idea. I like the idea of pairing with the CentOS folks for that, but I don't really know where to start there. This ecosystem has lots of information if you know exactly where to look. Otherwise, navigating it can be tricky. As for EPEL meetings, if we could have them again, I'd really try to be a part of it. Timing is crazy for a world-wide crew like this one. I'm completely -1 on /opt/blah for EPEL. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL epel beta report: 20140814 changes
Compose started at Thu Aug 14 08:15:02 UTC 2014 New package: admesh-0.98.0-1.el7 Diagnose and/or repair problems with STereo Lithography files New package: elixir-0.12.5-2.el7 A modern approach to programming for the Erlang VM New package: perl-Digest-Perl-MD5-1.9-3.el7 Perl implementation of Ron Rivest's MD5 Algorithm New package: perl-Jcode-2.07-15.el7 Perl extension interface for converting Japanese text New package: perl-Unicode-Map-0.112-31.el7 Perl module for mapping charsets from and to utf16 unicode New package: php-phpass-0.3-5.el7 Portable password hashing framework for use in PHP applications New package: python-GnuPGInterface-0.3.2-11.el7 A Python module to interface with GnuPG New package: python-cairosvg-1.0.7-3.el7 A Simple SVG Converter for Cairo New package: xemacs-packages-base-20140715-1.el7 Base lisp packages for XEmacs New package: yakuake-2.9.9-2.el7 A drop-down terminal emulator Updated Packages: librabbitmq-0.5.1-1.el7 --- * Wed Aug 13 2014 Remi Collet r...@fedoraproject.org - 0.5.1-1 - update to 0.5.1 - fix license handling - move all documentation in devel subpackage lxc-1.0.5-3.el7 --- * Mon Aug 11 2014 Jakub Čajka jca...@redhat.com - 1.0.5-3 - Fixed build dependencies on s390(x) and ppc(64(le)) python-fedmsg-meta-fedora-infrastructure-0.2.18-3.el7 - * Wed Aug 13 2014 Ralph Bean rb...@redhat.com - 0.2.18-3 - Upstream patches to fix further problems with the jenkins processor. syslog-ng-3.5.6-1.el7 - * Tue Aug 05 2014 Peter Czanik cza...@balabit.hu - 3.5.6-1 - Update to syslog-ng 3.5.6 (bugfix release) Summary: Added Packages: 10 Removed Packages: 0 Modified Packages: 4 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphaned packages with vulnerabilities
Hi, ... There is now a security initiative to handle the outstanding security bugs. that's cool that somebody cares however, do you really think that users will appreciate this way of handling the bugs, i.e. removing important libraries instead of patching them? Perhaps you can un-retire the package(s) and maintain them? why should I fix things *you* broke? Please calm down. If the package and its dependencies should stay in EPEL, they need to be maintained. probably my Google is broken, but I cannot find where this is set in stone? I've always thought that it works in the way that if package gets orphaned, it simply won't make it into next version of the distribution, not that it should get removed from the current version, causing regressions for users ...? So if you would like to have the package in EPEL, you need to find a maintainer or maintain it. sorry, I just don't follow your logic it wasn't me who did the action - why should I undo it? K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp ka...@jabber.cz :: Never attribute to malice what can :: easily be explained by stupidity. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphaned packages with vulnerabilities
Perhaps you can un-retire the package(s) and maintain them? why should I fix things *you* broke? If Eric didn't a) orphan the package in the first place, or b) remove the package from the repository... why are you saying he broke it? so, if he hasn't removed it himself but just asked someone else to remove it, he has no responsibility for the removal? All he did was say that these were orphaned packages which had other problems attached to them. all? - perhaps you've missed the quote from the ticket I posted just a few lines above, which you've cut from the reply? In the future, please follow this process instead: 1) Find out who removed the package. Till 2) Find out why they removed the package. because Eric asked epel-releng ... now I don't understand what are these two good for? 3) If the package was removed because it was orphaned, unmaintained, if I get the docs right, this is not a reason to remove a package - there's a difference between orphaning and retiring or not responding to CVE's that might be a reason - but in my opinion, the harm done by the removal is in this concrete case (libmodplug, haven't examined the other cases) worse than if we'd keep the vulnerable version ... this is desktop software, no important servers will end up in flames because of it; to compare, similar (stack corruption) issue exists in libtiff version shipped in RHEL5 yet I'm not aware that Red Hat would be planning to retire libtiff from RHEL5, while libtiff is by orders of magnitude more important (`yum remove libtiff` would take away half of my system, including e.g. java, cups or qemu ...) find a packager who can do so that the package can go back into EPEL or Fedora. it shouldn't have gotten to the point when we talk about go back the search should have been done *before* removing the package there was no ping, we're approaching this catastrophic scenario, isn't there someone able to handle this before I file request for removal? and also I can't find any trace that it would consider also the dependent packages, giving their maintainers a chance to step in or at least rebuild before the removal, avoiding broken dependencies K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp ka...@jabber.cz :: Never attribute to malice what can :: easily be explained by stupidity. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL libmodplug retirement in
On Thu, Aug 14, 2014 at 1:55 PM, Karel Volný kvo...@redhat.com wrote: last week, libmodplug got retired from EPEL (both 5 and 6), see https://fedorahosted.org/rel-eng/ticket/5960 But our users seem to miss it, it broke dependencies of qmmp and xine-lib. I know you've orphaned the EPEL branches a few years ago, however, I'd like to ask you to reconsider the decision. RHEL based desktop is still not dead I may reconsider that when/if I sometime start to use an EL based system that has some kind of use for or sensible means for audio output. But that time is not now, so I'm afraid it's a no thanks from me at the moment, someone else should look into it. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL libmodplug retirement in
On 14 August 2014 09:46, Ville Skyttä ville.sky...@iki.fi wrote: On Thu, Aug 14, 2014 at 1:55 PM, Karel Volný kvo...@redhat.com wrote: last week, libmodplug got retired from EPEL (both 5 and 6), see https://fedorahosted.org/rel-eng/ticket/5960 But our users seem to miss it, it broke dependencies of qmmp and xine-lib. I know you've orphaned the EPEL branches a few years ago, however, I'd like to ask you to reconsider the decision. RHEL based desktop is still not dead I may reconsider that when/if I sometime start to use an EL based system that has some kind of use for or sensible means for audio output. But that time is not now, so I'm afraid it's a no thanks from me at the moment, someone else should look into it. What would be a sensible means of audio output? -- Stephen J Smoogen. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL libmodplug retirement in
On Thu, Aug 14, 2014 at 6:49 PM, Stephen John Smoogen smo...@gmail.com wrote: On 14 August 2014 09:46, Ville Skyttä ville.sky...@iki.fi wrote: On Thu, Aug 14, 2014 at 1:55 PM, Karel Volný kvo...@redhat.com wrote: last week, libmodplug got retired from EPEL (both 5 and 6), see https://fedorahosted.org/rel-eng/ticket/5960 But our users seem to miss it, it broke dependencies of qmmp and xine-lib. I know you've orphaned the EPEL branches a few years ago, however, I'd like to ask you to reconsider the decision. RHEL based desktop is still not dead I may reconsider that when/if I sometime start to use an EL based system that has some kind of use for or sensible means for audio output. But that time is not now, so I'm afraid it's a no thanks from me at the moment, someone else should look into it. What would be a sensible means of audio output? Audio hardware, speakers, something like that. Anyway none of the EL boxes I use have anything that I could even effortlessly test libmodplug with. And even if I could, I wouldn't sign up for maintaining something I don't actually use, that kind of maintenance is not what I want from EL distros/packages. This is exactly why I stopped maintaining EL libmodplug years ago, and nothing has really changed since. The package needs a maintainer who actually eats his own dog food at least to some extent. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Testing documentation
Somebody asked me about one of my updates sitting in epel-testing today, and I noticed that we didn't have a nice page like we do for Fedora [1] that explains how the testing repository and bodhi, etc. work to point them to. So I forked the Fedora documentation and modified it to apply to EPEL instead: https://fedoraproject.org/wiki/EPEL/testing Hopefully others will find this useful. If I missed anything or you have anything useful to add, please use your wiki powers! Thanks, -T.C. [1] https://fedoraproject.org/wiki/QA:Updates_Testing ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Proposed meeting: Fri Aug 22 16:00:00 UTC 2014
I am proposing that the EPEL community hold a meeting in #epel on Friday August 22, 2014 16:00:00 UTC to go over various community items: Suggested topics: #topic Forking of EPEL packages to a faster moving repository a) Proposed name of repository is EPIC b) What packages stay, which packages go. #topic Setup and controls for said repository When do packages update in EPIC repository, how are they announced and where? #topic Review and cleanup of EPEL policies There was a problem with several packages being removed which broke other packages. These packages were removed because we have in the past not allow orphaned or non-maintain packages.. but where is this documented. #topic Open Floor Place for the meeting will be in #epel To determine when this meeting occurs in your timezone please type: date -d '2014-08-22 16:00:00 UTC' example: [smooge@seiji ~]$ date -d '2014-08-22 16:00:00 UTC' Fri Aug 22 10:00:00 MDT 2014 -- Stephen J Smoogen. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
