[EPEL-devel] Recent epel 8 branchs - no tag of package in epel
Hi, Last couple of days the epel8 branch requests have been processed okay. Thanks However when you then try and build something it results in BuildError: package X not in list for tag epel8-playground-pending Example: https://pagure.io/releng/fedora-scm-requests/issue/19622 https://pagure.io/releng/fedora-scm-requests/issue/19623 https://koji.fedoraproject.org/koji/taskinfo?taskID=38994106 has occurred for multiple recently branched packages. I think earlier in the week all was good. Steve. ___ 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
[rpms/perl-SOAP-Lite] PR #1: 1397732 - patch for CVE-2015-8978 (billion laughs attack).
stevetraylen commented on the pull-request: `1397732 - patch for CVE-2015-8978 (billion laughs attack).` that you are following: `` I merged this as I really thought I was the maintainer of this package. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-SOAP-Lite/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[rpms/perl-SOAP-Lite] PR #1: 1397732 - patch for CVE-2015-8978 (billion laughs attack).
stevetraylen merged a pull-request against the project: `perl-SOAP-Lite` that you are following. Merged pull-request: `` 1397732 - patch for CVE-2015-8978 (billion laughs attack). `` https://src.fedoraproject.org/rpms/perl-SOAP-Lite/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: [EPEL-devel] Question about EPEL 7 python-ipython*
On 02/27/2015 05:32 AM, Rahul Sundaram wrote: Hi On Thu, Feb 26, 2015 at 10:05 PM, Nordgren, Bryce L -FS wrote: I notice that ipython has not been released in epel7, but has a release version for epel6 and Fedora 20-22. Was there a decision to exclude it from epel, or is this due to lack of resources/interest? __ __ https://apps.fedoraproject.org/packages/python-ipython-notebook It is purely because noone has stepped up to do the maintenance. It is not explicitly excluded. That would only really happen if RHEL itself ships the package or if there are licensing problems See https://bugzilla.redhat.com/show_bug.cgi?id=1136051 which has had some progress recently. Rahul ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL CentOS curator group proposal
Excerpts from Antonio Trande's message of 2014-09-25 17:15:45 +0200: Hi Jim. On 09/25/2014 04:36 PM, Jim Perrin wrote: Earlier this week on the CentOS devel list I proposed an interim method to help make it easier for centos contributions to flow into epel. Essentially the proposal is that CentOS would like a 'curator' group (name can be determined later) similar to the wrangler's group. Members of this group would be responsible for shepherding packages designated by the various SIG efforts in CentOS through the process of getting these packages in epel. This means that rather than having an individual owner, packages would have group ownership. Members of this group will be required to have access to make package modifications on the CentOS side so that they meet the packaging standards for EPEL. Additionally, it would help to have an EPEL proven packager as part of the group as well in order to help make things move a little quicker. Would this be acceptable from an EPEL standpoint? What would be required from an EPEL perspective to make this happen? EPEL is for RHEL, Scientific Linux, Oracle Enterprice other than CentOS; would we need of special curator group for every distro? CentOS contributions could flow simply by taking part on EPEL and by integrating any special (previously discussed) packaging need . This would be my take also, getting pkgs into EPEL is a pretty well defined process as is a becoming a packager. I don't see an extra step/group is needed within CentOS is needed. Group ownership of pkgs in EPEL? So many people can own a package already. I am unsure what the 'wrangler' group example is. -- -- Steve Traylen, CERN IT. ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Orphaning json_simple
Hi, I am orphaning json_simple Steve -- -- Steve Traylen, CERN IT. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning json_simple
Excerpts from Josh Boyer's message of 2014-09-15 16:39:53 +0200: On Sep 15, 2014 10:37 AM, Steve Traylen steve.tray...@cern.ch wrote: Hi, I am orphaning json_simple Why? It's the only piece of java in my packaging life and the packaging became hard where I need to learn all the maven macro stuff to fix bugs. Happy to maintain while trivial though can't justify more. Steve. josh -- -- Steve Traylen, CERN IT. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
torque orphaned in rawhide.
Hi, I've disowned torque in rawhide (f18). I'll maintain older fedora and epel = 6 for their lifetime and am very happy to collaborate with a new maintainer. Steve. -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning ndoutils
ndoutils - Stores data from Nagios in a database. is now orphaned. -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning pyactivemq
Hi, I'm orphaning pyactivemq within rawhide only. I've not used it for a couple of years now and upstream has stalled. In particular it no longer builds against newer version of activemq-cpp though it's probably easy to fix. http://code.google.com/p/pyactivemq/issues/detail?id=38 Steve. -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning: xmltooling, glite-security-*, opensaml,
Hi, I'm orphaning xmltooling - this has some hard to fix or pain to avoid needs for an openssl built curl. opensaml - requires xmltooling. glite-security-util-java glite-security-trustmanager Steve. -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package for Fedora and EPEL from one spec source?
On Tue, Feb 1, 2011 at 3:23 PM, Gerd v. Egidy li...@egidy.de wrote:
Hi,
I've submitted my first Fedora package for review and sponsoring recently:
https://bugzilla.redhat.com/show_bug.cgi?id=673175
I want to submit it for Fedora and EPEL 5. The differences between the two
are
minimal, there are just some programs missing in EPEL which need to be
commented out in the default config.
This page
http://fedoraproject.org/wiki/DistTag
and the buildsys macros RPM on EPEL5 should help you.
http://buildsys.fedoraproject.org/buildgroups/rhel5/x86_64/
yes is perfectly possible to have one .spec file for all at the start though
they may diverge due to difference update policies in particular.
Steve.
What is the best way to handle this? Can I keep one spec for both and use
conditionals to always build the right way?
I've seen code like %if 0%{?rhel} somewhere on the net, but that didn't
work
for me. I guess the %rhel-macro should be defined in /etc/rpm/macros.dist
where I usually find stuff like %fedora but that doesn't exist on my Centos
5.
Or am I supposed to create a completely separate .spec for EPEL once the
review, sponsoring etc. for Fedora is done?
Kind regards,
Gerd
--
Address (better: trap) for people I really don't want to get mail from:
jo...@cactusamerica.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Steve Traylen
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Fri, Dec 10, 2010 at 7:15 PM, Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp wrote: Toshio Kuratomi wrote, at 12/11/2010 02:00 AM +9:00: On Fri, Dec 10, 2010 at 08:40:23PM +0900, Mamoru Tasaka wrote: Thomas Moschny wrote, at 12/10/2010 08:19 PM +9:00: That seems by far the cleanest solution to me. Especially development-oriented packages often contain example directories; removing x-bits there only puts extra-burden on someone trying to play with the examples. Indeed some examples/ directory contains some executable scripts which are useful to understand what the package can do. I think %doc files must not have executable permissions must be reverted. To my mind, if you have examples that you want to be runnable by the user and you want them to not have to perform chmod 0755 to achieve that, you'd also want rpm to ensure that the dependencies for those examples are installed. So, when a package - contains some example scripts - the packager thinks that such scripts are useful and many people actually want to execute them - but such scripts need additional dependencies then the packager actually may want to add additional dependencies. So - Loosen the guideline to %doc files should not add too much additional dependency - If executing %doc scripts want some large additional dependency, move such scripts to somewhere else (out of /usr/share/doc, e.g. %_libdir/%name/examples), or create subpackage like %name-examples ? (By the way I think in most cases additional dependencies are actually not needed) /usr/share/doc contains documents for reading and part of learning may well include reading example scripts, leave them there for reading. If you have a script that should actually be executable as installed on the system then move it to /usr/bin and if sensible put it in an -examples sub package. You can go either further and say that /usr/share/doc must be readable. e.g including a .tex file is bad practise but a .pdf make sense. Steve. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/xml-security-c/EL-6 xml-security-c.spec,1.5,1.6
On Mon, Jun 21, 2010 at 3:34 AM, Dennis Gilmore den...@ausil.us wrote:
umm why did you make that change?
On Sunday, June 20, 2010 03:06:32 pm stevetraylen wrote:
Author: stevetraylen
Update of /cvs/pkgs/rpms/xml-security-c/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv2536
It's the same upstream software in devel as in EL-5.
However devel has some release bumps for .so updates to underlying
xerces 2 - 3 that happened in Fedora but not RHEL.
The devel or F12 would have worked but EL-5 has a more consistent relevant
changelog with out a release bump which is irrelevant/misleading in this case.
Steve.
Modified Files:
xml-security-c.spec
Log Message:
EPEL5 one better than F12 for EPEL6.
Index: xml-security-c.spec
===
RCS file: /cvs/pkgs/rpms/xml-security-c/EL-6/xml-security-c.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- xml-security-c.spec 21 Aug 2009 16:32:47 - 1.5
+++ xml-security-c.spec 20 Jun 2010 20:06:31 - 1.6
@@ -1,6 +1,6 @@
Name: xml-security-c
Version: 1.5.1
-Release: 2%{?dist}
+Release: 1%{?dist}
Summary: C++ Implementation of W3C security standards for XML
Group: System Environment/Libraries
@@ -81,9 +81,6 @@ rm -rf $RPM_BUILD_ROOT
# %doc CHANGELOG.txt
%changelog
-* Fri Aug 21 2009 Tomas Mraz tm...@redhat.com - 1.5.1-2
-- rebuilt with new openssl
-
* Tue Jul 28 2009 Antti Andreimann antti.andreim...@mail.ee 1.5.1-1
- New upstream relase (#513078)
- Fixes CVE-2009-0217 (#511915)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Steve Traylen
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: python 2.7?
2010/6/10 Michał Piotrowski mkkp...@gmail.com: Hi, 2010/6/10 Phil Knirsch pknir...@redhat.com: On 06/10/2010 01:49 PM, Neal Becker wrote: python 2.7 seems to have a number of exciting improvements for the python 2 series. Any plan to introduce it into fedora? http://doc.python.org/dev/whatsnew/2.7.html If i remember correctly the plan is to move to python-3.x at some point. Now that we ship Fedora-13 with a python3 compat package and can much easier adapt all things depending on it. Are there any chances to get Python3 packages for EPEL6? There's an RFE here, the package needs some work but nothing that is not understood. https://bugzilla.redhat.com/show_bug.cgi?id=591958 Only open question is if it should be python3 or python3X. Best to comment in the bug if you have opinion I would say. Steve. Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can anyone contact torque/perl-PBS maintainer.
Dear member of Fesco, I believe I have now followed the non-responsive maintainer process for packages torque and perl-PBS. Please can some one check this over and assign them over to me if everything is in order. Many Thanks, Steve Traylen (fedid = stevetraylen) On Mon, May 31, 2010 at 6:00 PM, Steve Traylen steve.tray...@cern.ch wrote: Following the process https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Is someone able to get in touch with maintainer of torque and perl-PBS. Fedora id = garrick Bug https://bugzilla.redhat.com/show_bug.cgi?id=590487 details the previous attempts made over the last couple of weeks. Steve Traylen. -- Steve Traylen -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can anyone contact torque/perl-PBS maintainer.
On Mon, Jun 7, 2010 at 6:38 PM, Kevin Fenzi ke...@scrye.com wrote: On Mon, 7 Jun 2010 18:19:01 +0200 Steve Traylen steve.tray...@cern.ch wrote: Dear member of Fesco, I believe I have now followed the non-responsive maintainer process for packages torque and perl-PBS. Please can some one check this over and assign them over to me if everything is in order. Yep. Everything seems to be ok here. I have released ownership in pkgdb. Please take them. I'll note that garrick has 2 other packages: aalib perl-Curses perl-Curses I'll take definitely as it's a dependency, just forgot when I doing this email. aalib I'm not interested in, nothing seems to require it. Steve. Perhaps some folks would also like to take those over since garrick is away? kevin -- Steve Traylen (fedid = stevetraylen) On Mon, May 31, 2010 at 6:00 PM, Steve Traylen steve.tray...@cern.ch wrote: Following the process https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Is someone able to get in touch with maintainer of torque and perl-PBS. Fedora id = garrick Bug https://bugzilla.redhat.com/show_bug.cgi?id=590487 details the previous attempts made over the last couple of weeks. Steve Traylen. -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EL-6 mono build
On Mon, May 10, 2010 at 6:50 PM, Itamar Reis Peixoto ita...@ispbrasil.com.br wrote: mono requires bootstrapping ? http://koji.fedoraproject.org/koji/buildinfo?buildID=172787 how to build it ? Hopefully you can disable enough features on one package such that it will build so it can then become a dependency to the next package. Then reenable the missing features on the original package. You just bump the .spec release at each build. Steve. -- Itamar Reis Peixoto -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing spec files
On Mon, Mar 8, 2010 at 5:50 PM, Matt Ford matt.f...@manchester.ac.uk wrote: Hi All, I am looking at building a fedora package. I have been over guidelines and taken a look at the build system. What I am not clear on is how I maintain spec files for different distributions i.e., F12, F11, F10, or even EPEL. Initially to have a package added in principal it only has to work on rawhide for release with the next release. Do I have to branch and maintain each spec file separately or is there a better way? Are there any tools that abstract the commonality? Do people try to write spec files that work on any distro with conditionals? It is true that the separate .spec files are maintained separately. What many people try and do is maintain them as identical, at least at the start. Have a look at: http://fedoraproject.org/wiki/Packaging/DistTag#Conditionals of course with time with different update policies it will happen that say EPEL and rawhide .specs diverge. Thanks for any wise words, Matt. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
