[EPEL-devel] EPEL and the new distribution-related macros
Quite recently a few macros were added to fedora-release: %dist_vendor, %dist_name, %dist_home_url and %dist_bug_report_url. These will eventually be documented in the Fedora packaging guidelines and you can see the initial PR at https://pagure.io/packaging-committee/pull-request/1198 I was considering how this interacts with EPEL. If these macros are not added to RHEL then EPEL could just define them with EPEL-appropriate values and all is well. But if they are added to RHEL, EPEL will need to decide if the values used by Red Hat (or whatever base distribution is being used to build) are appropriate. And if not, is it appropriate for EPEL to override the RHEL values? (This was done back in the EPEL6 days so there is precedent but that was a long time ago.) - J< ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: RFC: generating openssl3 packages from openssl spec
> Troy Dawson writes: > If I remember right, the spec file name needs to be in the format > .spec Thus, the spec file needs to be > openssl3.spec, and thus you aren't really renaming it. :) Yes, assuming that EPEL doesn't deviate: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_file_naming I believe various tools will make the assumption that the specfile is named accordingly. - J< ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Koschei enablement for EPEL 8
> "SJS" == Stephen John Smoogen writes: SJS> Can koschei be limited to a single architecture or does it need to SJS> build against all targets? I am worried about the number of s390 SJS> builds we may be adding. Currently it only does builds for aarch64, ppc64le and x86_64, so it does at least know how to avoid building on everything. In addition, it is pretty good about not submitting jobs without plenty of idle builders to handle them. Back when it was first being deployed, koschei did swam the s390x builders but that was fixed. And these days, s390x isn't really our slowest architecture. - J< ___ 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: Fedora EPEL 8 updates-testing report
> "PW" == Phil Wyett writes: PW> The '.1' should go before the %{?dist} tag in this case so to not PW> confuse as the outputted 'el8.1' does. This is not true: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_you_need_to_change_an_old_branch_without_rebuilding_the_others And in addition, the Release: tag must be an integer unless it is capturing additional upstream versioning information such as prereleases or snapshots: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_simple_versioning and https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_more_complex_versioning I'm not aware of any EPEL-specific exceptions to those. - J< ___ 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: policycoreutils-python, audit-libs-python required for certbot for CentOS7 in need of updating
The issues you show don't appear to have anything to do with EPEL. The certbot package simply requires /usr/sbin/restorecon and /usr/sbin/semanage; yum isn't able to install those because it appears that there is some problem with the base (Centos) repositories. Please make sure that you are able to update your system and install policycoreutils-python and audit-libs-python on their own without errors. (Of course the issue might already have cleared itself up by the time you try.) If you are, then you should be able to install certbot. - J< ___ 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: Backporting fuse3 and fuse3-libs rpms to EPEL
> "DD" == David Dykstra writes: DD> Does this also imply a new fuse3 package in pagure & bodhi? Or DD> could it still be part of the fuse package but have a separate DD> fuse3.spec? It would have to be a separate package repository and receive separate updates. It is not possible for a source package in EPEL to have the same name as a source package in RHEL, even if the build products (binary RPMs) have different names. Note that a package review is not required to create a package repository named "fuse3" (or "fuse3.7" or whatever) when the "fuse" package repository already exists. See https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process When running fedpkg request-repo, use the --exception flag. - J< ___ 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] Retirement of denyhosts
The denyhosts software has only been lightly maintained in EPEL for many years; the EPEL6 branch could have been considered to be unmaintained. It does not properly support modern system features such as systemd or firewalld and generally expects to be able to make use of the hosts.deny file. It appears to be mostly unmaintained upstream. (A beta release appeared in 2015 but nothing seems to have happened since then.) Since I have retired the software in Fedora, I have also retired it in EPEL6 and EPEL7. It should disappear from the repositories soon. If you have it installed then of course it isn't going anywhere, and all of the packages which were released will still be available from the Fedora build system at https://koji.fedoraproject.org/koji/packageinfo?packageID=1585 Should someone wish to do the work to keep the software alive in EPEL (or in Fedora), I will certainly be happy to help get that set up. Otherwise, if you are using the EPEL denyhosts packages, I would strongly suggest that you consider using fail2ban instead. - J< ___ 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: Moving EPEL7 to python3.6
> "NG" == Neal Gompa writes: NG> Wait, we can do that? I thought we couldn't use the exception NG> process for this? Well, the idea is that you don't need a separate review just to import a different version of the same package. So foo and foo1.2 (the 1.2 version) or python-abc and python36-abc (the python 3.6 version). The package itself is going to be pretty much the same thing in either case. - J< ___ 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: Moving EPEL7 to python3.6
> "OP" == Orion Poplawski writes: OP> - Can we make epel7-py36 branches, and somehow have OP> %python3_version, et. al. be 3.6 for those builds? I can't think of any way to do that without extra magic. And if you require something in the spec, you might as well just hardcode it. OP> - Can we just make it easier for people to create python3X- packages OP> from existing python3- or python3(X-n)- packages? And just drop the OP> whole macro thing altogether, since sed -i -e s/pyton34-/python36-/ OP> *.spec does 90% of the work? Right now the process is: fedpkg request-repo --summary "Summary of foo" --exception python36-foo fedpkg request-branch --repo python36-foo epel7 (wait) fedpkg clone python36-foo cd python36-foo fedpkg retire "This is an EPEL-only package" fedpkg switch-branch epel7 And then copy in your spec and sources, edit and go. There is no need for a package review. That's certainly a few steps but far from the worst process in the distro. What could we do to make it easier? - J< ___ 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: python2-jenkins-job-builder package version
> "RI" == Roman Iuvshyn writes: RI> I have a question related to *python2-jenkins-job-builder RI> *package, who maintains this? https://src.fedoraproject.org/rpms/python-jenkins-job-builder shows all of the maintainers. RI> currently available version in epel is pretty old and I wonder if RI> there any plans to update it to the recent version? Did you file a ticket requesting an update? I don't see one. Maintainers are generally going to be very reluctant to update a package in EPEL without some pressing need. Not generally as reluctant as Red Hat would be for a package in RHEL7 proper but you would still need to ask. - J< ___ 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/message/I4GMJ57PQ3SJ6RUFHKNU3HAM3TNNARLE/
[EPEL-devel] Re: Package Updates: python-passlib
> "SJS" == Stephen John Smoogen writes: SJS> This looks to be one of those packages which are only in EPEL for SJS> users of the aarch64 and ppc64 architectures. I wonder how you can tell. The specfile doesn't indicate anything about it. - J< ___ 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/message/RXRWUPJN4QGZYKKW6CCVQ6Q7T6BWFZOB/
[EPEL-devel] Re: When does a retired package get removed from the EPEL repository?
I asked on IRC and mboddu had a look; somehow the retirement didn't automatically filter into the PDC (which keeps all sorts of metadata about packages) and so nothing else in the system noticed. There were sporadic problems with this in the past (which have been fixed for a while) but a few retirements may have been missed. This has been corrected now; https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=heketi=epel7 shows that the package is not currently active on the EPEL7 branch. This should propagate into koji with the next compose, so the package should disappear from the mirrors within a day or two. - J< ___ 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/message/DG26KUAOBAVGXCHQ2XVPUYAHAOGCBU3B/
[EPEL-devel] Re: When does a retired package get removed from the EPEL repository?
> "NdV" == Niels de Vos writes: NdV> I think I followed [1] correctly, but the package is still NdV> there. Could someone have a look at the commit [2] with NdV> dead.package in it and advise me what I did wrong, or what steps I NdV> have missed? You linked to the document, but did you read through this section: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Koji You've certainly waited long enough, so you should file a ticket in the tracker linked in that section. - J< ___ 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/message/ZRWXGFT6X4PJMSOGY6VNAUT4PTFI5SF5/
[EPEL-devel] Re: epel-testing yum update cron errors
Also, when I look at the four updates you listed, I see that they are all recent and that they are all currently in stable, not testing. Perhaps you are pulling from a mirror which is out of date and still has old data for epel-testing? If you do 'yum updateinfo list', I believe it will tell you all of the relevant updates (though disappointingly not whether they're in epel-testing or in stable) and will also tell you which mirror it is using for which repository. You can also try doing 'yum clean all' which I think will refresh the list of mirrors it uses. Finally, you can try disabling the fastestmirror plugin (by editing /etc/yum/pluginconf.d/fastestmirror.conf) if you are consistently getting sent to a bad mirror. - J< ___ 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/message/62PDQBH5I2DLJLWDBMHLRMVYEHM6G4QN/
[EPEL-devel] Re: epel-testing yum update cron errors
> "p" == postmaster writes: [...] p> consider re-running the same command with --verbose to see the exact p> data that caused the conflict. Could perhaps you re-run the same command with --verbose so that we can see the exact data that caused the conflict? I run yum-cron with epel-testing enabled and don't see this, but perhaps you have modified /etc/yum/yum-cron-hourly.conf. If you've made any modifications, could you share them? - J< ___ 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/message/JJJ5DCH5BGTAX4XYP2JRITZ6I4V2LEFD/
[EPEL-devel] Please test epel-rpm-macros changes
Just a note that I've backported the %set_build_flags macro from Fedora to EPEL6 and EPEL7. Updates are at: * https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-99aa68bf61 (EPEL7) * https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-6b0faf2b25 (EPEL6) Buildroot overrides have been filed so these should be live for koji builds now. Please test and give karma. Thanks! Other changes in those macros in the past few months, all of which enhance specfile compatibility with Fedora: * Added the %build_cflags, %build_cxxflags, %build_fflags and %build_ldflags macros. * Added %_rpmmacrodir * Added %_metainfodir * Added %vimfiles_root * Added the varions ldconfig macros (%ldconfig, %ldconfig_post, %ldconfig_postun, %ldconfig_scriptlets, %ldconfig_post, %ldconfig_postun) which do the right thing across all releases. And while I'm typing If you have to use conditionals (or maintain a separate specfile) to work around python2-* packages being called python-* in EPEL, please see https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages Many of the most common cases are already fixed for you and python2-* works everywhere. Feel free to request any that you need. - J< ___ 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/message/P73VCTJJVH2YX3QVV3DDMVHU47FCYNHE/
[EPEL-devel] Re: yum does not find a package that I submitted to EPEL7 stable
The package should appear in the repositories with the next EPEL7 compose. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: yum does not find a package that I submitted to EPEL7 stable
> "GM" == Germano Massullowrites: GM> but esteidcerts package is in EPEL7 *stable* repositories [2], so GM> why do I get such message? That update report indicates that it was pushed to stable, but as far as I can tell it does not actually appear in the stable repository. It's not on either of my local public mirrors and it doesn't appear to be in the master mirror: rsync rsync://dl.fedoraproject.org/fedora-epel/7/x86_64/Packages/e/ has no mention of esteidcerts. This is probably an issue with bodhi or the compose process; I'll ask the admin folks to look into it. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Python2 stub packages now in EPEL stable
The initial set of stub python2-* packages I created have now made their way to EPEL6 and EPEL7 stable, so packages can now depend on python2-setuptools, python2-six, python2-pytest and python2-sphinx in all releases without having to add conditionals for EPEL. Feel free to suggest additional packages; I will be happy to create them. See https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages for more information. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Dummy python2 packages submitted
All of the initial run of packages have been submitted now. See https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages for the complete list of builds. Please test and give karma. Thanks, - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Dummy python2 packages submitted
It would of course be better if I actually provided links to the updates: python2-setuptools (EPEL6): https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-92c3e1b0e4 python2-sphinx (EPEL7): https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9cd64dfc3c python2-pytest (EPEL7): https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a878cfb2c5 python2-six (EPEL7): https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-92c3e1b0e4 - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Dummy python2 packages submitted
(This is mostly a duplicate of a post I sent to devel@. I wanted to alert epel-devel@ but didn't want to crosspost.) Following my proposal in https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages which met with favor from a number of folks here, I went ahead and set up four dummy packages: python2-setuptools (in EPEL6) python2-sphinx (EPEL7) python2-pytest (EPEL7) python2-six (EPEL7) I'll do EPEL6 versions of the latter tomorrow. (I forgot that I can only request one branch with the initial repo request. Oops. In my defense, that's a really odd restriction.) These should, once actually pushed to stable, allow you to avoid having to add conditionals to depend on setuptools/sphinx/pytest/six in EPEL. If this works out for folks, I (or anyone else) can potentially add similar dummy packages for every package which needs one. Anything to cut down on those conditionals. Please check my work, test and give karma as appropriate. They seem to work fine for me when I set up a local repo and do some mock builds, but I only have access to Centos so I guess anything is possible. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: ansible1.9 package
> "SJS" == Stephen John Smoogenwrites: SJS> OK how can we better explain this in the future? I really tried, in the "Can I rely on these packages?" section of the EPEL wiki page: https://fedoraproject.org/wiki/EPEL#Can_I_rely_on_these_packages.3F Someone already quoted that in a list message. But if people don't read the relevant web pages then I don't know what we can do. We can't mail root weekly to remind them that EPEL stuff isn't RHEL stuff and doesn't come with the same support guarantees. We can't wrap the download of the epel-release package in a click-through thing where they have to indicate their understanding. It's simply true that there will always be someone who, for whatever reason, ignores everything we say and carries a different understanding of what EPEL's promise to the community is. It's the same thing that drives people to say "you took something away from me" when we retire a package, even though you can still get the package. And to say "you should support my use case" even though that use case is at odds with reasonable principles of security. I don't think it's any coincidence that all three of those have come up in this one thread. I don't think there's really anything we can do about it besides making sure the relevant language is available in the right places. And learning to not be bothered when we've met our promises but not someone's misunderstanding of what our promises are. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Stub python packages for EPEL
> "KF" == Kevin Fenziwrites: KF> I don't think we have any way to find out the version of a package KF> in all channels. At least I don't know of such a way. So, I think we KF> should concern ourselves with only the channels that EPEL says it KF> will try and not conflict with. I don't even know what those are, really. All I know is what I can extract from those json files, and what CentOS has. Certainly limiting things to what EPEL can see is the only reasonable way; I was just trying to hedge against the fact that I can't see what's in KF> So, yeah, we would need to make sure and retire the epel package as KF> soon as rhel started providing a source package with the same name. I think it is somewhat unlikely that RHEL would begin providing any python2-X source packages where they currently provide python-X source packages. I guess it's possible, though, and it's something we'd have to deal with immediately if it ever happens. However, it shouldn't cause issues for end-user systems in that case, only the EPEL builders, and for those the fix is very quick (block in koji and wait for a newrepo). KF> I'm in favor... lets give it a try with some of the common ones. :) Thanks; I have a list of four I'm starting with, listed at the end of https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages I hope that once in this will make life easier for someone. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Stub python packages for EPEL
One of things I've invested some time towards over the years is cutting down on the amount of %if spaghetti needed to share spec files between Fedora and EPEL. Earlier in the discussion about the mass python-X -> python2-X move I volunteered to maintain a number of "stub packages" in EPEL which have the sole purpose of letting packagers uniformly have dependencies on python2-X. A couple of people told me they thought I was being facetious, so I wanted to try again and assure everyone that I was indeed serious. Here's a rough, in-progress draft: https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages Basically: create some EPEL-specific python2-X packages that do nothing besides depend on the base RHEL python-X packages. If anyone can think of a reason why this would be problematic, please let me know. I'm especially concerned about situations where the existence of these packages could cause problems for RHEL. I've tried to be careful about detailing how version and release would be maintained and how the dependencies will be versioned so that RHEL can be updated without the EPEL package being immediately updated to match. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Thinking about how to provide an updated cyrus-imapd
I've been doing a lot of packaging work on the Fedora version of the cyrus-imapd package, including a lot of work with upstream to do things like run their external test suite as part of the package build process, and fix issues that only show up on 32-bit or big-endian architectures. One thing they asked me is whether it would be possible to provide packages for their current version to EPEL7, since the version in RHEL7 is extremely old and lacks a significant amount of functionality. So I've been looking into it and wanted to see if I could create a package which would be even remotely acceptable under EPEL rules. Obviously the package couldn't be named "cyrus-imapd", so I'd use "cyrus-imapd3" instead. Obviously I would have to avoid conflicts with the base EL7 package. * Internal daemons and such would just go to a different directory. * User-facing executables would have to be renamed or placed somewhere outside of the PATH. Or both: placed outside of PATH with original names, and with non-conflicting symlinks in PATH. * Manpages would need to be renamed to be in a separate section. The package would need the PAM configuration be in place. Unfortunately these are just generically named files in /etc/pam.d: csync, imap, lmtp, mupdate, nntp, pop, sieve. In both RHEL and Fedora, these are provided both by the cyrus-imapd and uw-imap packages. They don't conflict because the files are identical between these packages. Is it acceptable for a package to do the same thing? Can my hypothetical cyrus-imapd3 package provide the same files as the base RHEL cyrus-imapd and uw-imap packages? There would be no conflict because the files would be the same. I could also just leave them out and leave it to manual configuration, I guess, but that seems suboptimal. Some dependencies in EL7 are pretty old, but that can be worked around: * libical is in base RHEL7 and is quite old. I would need to either bundle or separately package libical 2. jansson might barely be new enough, but if not then I'd be bundling or separately packaging lansson2.10. xapian-core is in EPEL, but the version is too old. I can ask the EPEL maintainers about an update but I would probably need to bundle or separately package this as well. So this seems like a lot of work. If I didn't care about conflicts I could just toss up a COPR and let upstream pretend it's official. But being in EPEL has benefits, I guess. If anyone is interested in working on this, or just has any ideas about how I can do this without running afoul of EPEL's packaging rules, please let me know. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Pull request/Changes to CentOS Extras repo??
> "SJS" == Stephen John Smoogenwrites: SJS> Things don't work that quickly. Well, they can work pretty quickly when the stars align. SJS> We have processes that need to be followed for packages to be SJS> reviewed and such. I would argue that reviews aren't actually needed due to the exemption about different versions of existing packages. I guess maybe that's stretching it just slightly (since that's mainly about adding, say, python-sqlalchemy1.1 without review instead of python3-sqlalchemy), but I would be perfectly happy to click the necessary button there. The only finesse involved is making sure that package gets blocked in Fedora so that it only makes it into EPEL. That's no different from any other EPEL-only package. SJS> If you are not already a Fedora packager there will need to be SJS> steps to become one. Which shouldn't be too hard if Martin is prepared to be the maintainer of these things long term. There should be enough sponsors around reading this that someone is willing to help out. Me included if Martin is willing to hit me up on IRC. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: OFFLIST Re: rh-epel] END OF LIFE FOR EPEL-5 (2017-03-31)
> "RPH" == R P Herroldwrites: RPH> question / thought as to a possable extensionto the outline -- can RPH> a 'final' revised EPEL yum repodata update be issued pointing to RPH> the new location (and the move and later remove staged in two RPH> pieces), so existing users can get repoclosure? There is no need; the repository files shipped by EPEL point to mirrormanager, which will direct users to the proper location. Of course, the set of potential mirrors will be smaller as there are fewer sites which mirror the archive. It will be interesting to see if this appreciably increases traffic to my mirrors. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Major updates to nagios and nrpe
> "SJS" == Stephen John Smoogenwrites: SJS> Selinux may have issues and I am trying to work through a proper SJS> way to update the selinux policy for it without over-writing items. You might need new policy if the new nagios does things that the old one didn't, like call out to different programs, connect to different network sockets, etc. However, since you moved files around, your biggest problem would be file contexts. Best thing to do is look at the existing rules: # semanage fcontext -l | grep nagios will show you: /var/spool/nagios(/.*)?all files system_u:object_r:nagios_spool_t:s0 /var/run/nagios.* all files system_u:object_r:nagios_var_run_t:s0 /var/log/nagios(/.*)? all files system_u:object_r:nagios_log_t:s0 So, hmm, the existing policy does already categorize things in those directories differently, and moving things around between those directories might upset the existing policy (though it might not). You'll definitely want to run permissive for a bit and collect AVCs. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: NOTCE: Red Hat Enterprise Linux 5 Three-Month Retirement Notice
> "PR" == Peter Robinsonwrites: PR> Reminder that RHEL 5 and hence EPEL 5 has got 3 months until EOL. PR> Packages now should really just be in bugfix and security fix only PR> mode. Should we be preventing the branching of new packages for EPEL5 at this point? We can probably get that switch thrown in phgdb. It would be analogous to the month of "updates but no new packages" in the (current - 2) Fedora release. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Should we announce package removals?
Hanging out in #epel on IRC, I've seen multiple people come by to ask where a particular package went after it's been removed. And I just realized that the orphaned packages report is sent only to epel-devel, so someone subscribed just to epel-announce wouldn't see anything at all. I don't have any spare time to volunteer to make this happen, but I wanted to point out that this is something of a problem that's hitting real people. I think ideally a summary list containing both packages being removed and those in danger of being removed (maybe, 2 weeks orphaned or something like that) should be sent to the announcement list weekly, preferably with some kind of basic explanation of what's happening and why. At minimum it would help eliminate some of the surprise and panic when packages go away (assuming people bother to subscribe). And at best it might give a wider audience to pending package removals and might encourage some people who rely on an orphaned package to volunteer. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: EPEL5 man page compression
> "RF" == Richard Fearnwrites: RF> I'd have thought that instead of specifying "%{_mandir}/man1/foo.1*" RF> as the guidelines suggest, it would be safer to specify RF> "%{_mandir}/man1/foo.1.*" to ensure it doesn't accidentally pick up RF> an uncompressed file. You also have no guarantee that files will be compressed. The scripts that do this behind the scenes could decide not to compress them for some reason. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL5 man page compression
> "RF" == Richard Fearnwrites: RF> Thanks Jason for looking into this, and for your work on these RF> macros in general. I take it you mean you were able to build the old RF> version of the package (1.12-1) without issue? Yes, it builds with and without a %clean section. I tested a few other packages and they built fine as well. I will note, though, that the guidelines recommend not specifying the extension of the manpages in the %files section; you can't guarantee that gzip will always be the compression format used. That's probably why more packages never ran into this and why my "random sample" build tests didn't fail. I need to do a full rebuild before pushing this as an actual update in any case. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL5 man page compression
I have developed a workaround for the issue you reported. I am able to build your package without issue. I have submitted the updated package to testing and I would welcome any testing. In the meantime I will set up another complete el5 rebuild to double-check. Alternately, I could simply remove the %clean magic entirely. RPM itself doesn't care if there's no %clean; it just leaves some cruft around when doing rpmbuild. Obviously mock won't care at all. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL5 man page compression
Yeah, this is a sadly unintended side effect of the magic I had worked out to make %clean optional. Instead it introduced situations where %clean needed to be removed (but, of course, not every situation). I'm still thinking about ways to handle it, but EPEL5 is fortunately not long for this world anyway so I'm weighing now much effort it's worth to perfect rather than just removing it. Or just removing %clean from every existing EL5 spec, which might actually be preferable. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds
> "d" == daniwrites: d> I think it is high time to rethink the single version of a package d> policy, and come up with some scheme that would allow for any package d> to maintain multiple versions in a consistent manner. We don't have such a policy. At least Fedora doesn't. In fact, adding another version of an existing package doesn't require a pass through the review process. The packages just need to not conflict and be named appropriately. Dealing with the names of binaries is left up to the packager. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: python34 for EPEL6
> "AL" == Avram Lubkinwrites: AL> I'm curious if anyone else has any insight. Maybe it is worth AL> bringing up at a FPC meeting. That would more appropriately be a topic of an EPEL meeting, since this is purely an EPEL policy issue. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: python34 for EPEL6
> "AL" == Avram Lubkinwrites: AL> Not needing reviews would help, but I wonder how hard it would be to AL> make them children of python-PACKAGE. The main issue is the SRPM AL> needs to have a different name so there is no conflict with the RHEL AL> SRPM. To be completely fair, I don't actually know EPEL policy here. The rule is that you can't conflict with RHEL packages, but SRPMs aren't really installed the same way as other packages and whether or not they would install to the same location depends somewhat on your personal .rpmrc. It's probably been discussed somewhere and I just don't recall, but it's definitely worth asking someone who can answer properly. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: python34 for EPEL6
> "AL" == Avram Lubkinwrites: AL> Definitely, but it runs into the same problem as 3.4 on EL7, the AL> fact that there are few packages available and adding them when the AL> package already exists in RHEL requires creating a separate parent AL> package in Fedora pkgdb. Which is an annoying bit of process, but it would be quite possible to exempt those packages from needing package reviews. It needn't take that long. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds
> "DJ" == Dave Johansenwrites: DJ> devtoolset is designed to do all of this and is already done, so it DJ> seems that the only advantage to putting it in EPEL itself would be DJ> to reduce the number of repos during build time. So is devtoolset something I get access to as a CentOS user? How do I build these packages myself (i.e. in mock)? - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Python macros for EPEL6 available in testing
I added a set of python macros to epel-rpm-macros-6 and pushed them out to testing. This should allow you to use the all of what's in the regular Fedora Python guidelines as is. You will still have to %if out some of the python3 stuff (build deps, subpackage declarations, %files, etc.), but things like %py3_build can stay as they simply have no effect. Eventually I'll get back to the additional macros I've been writing which should require even less %if-ing over the full range of Fedora/EPEL releases. But for now, these should help. I haven't had enough free time to give these more than some basic testing. Please enable the testing repo in mock and give them a try. If things go well, I'll push them to EPEL5 later. What's been added: %__python2 %python2_sitelib %python2_sitearch %py2_build %py2_install %py3_build (nil) %py3_install (nil) %py_setup %python_provide Let me know if I missed anything, or screwed up somewhere. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] %autosetup now in EPEL5 and EPEL6 proper
Just FYI, EPEL5 and EPEL6 now have functioning %autosetup implementations. For EPEL6 there are no caveats; for EPEL6, if you have patches numbered higher than Patch9: then you will need to set %el5_patches_limit appropriately. But, uh, why would you do that? All documented at https://fedoraproject.org/w/index.php?title=EPEL:Packaging shortly. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Simplifying use of Python 3 macros?
> "DJ" == Dave Johansenwrites: DJ> Is there anything that could be done in EPEL to make the Python 3 DJ> macros be usable without requiring %{python3_pkgversion}? Well, there has been some on and off work focused on making python packaging less hideous. A spec would look sort of like this: https://pagure.io/python-macros/blob/master/f/test1.spec And I think that would work down into EPEL. But otherwise, there's not much we can do about that _pkgversion macro, since EPEL may even get multiple python versions at some point. The fancy macros actually handle that, but they aren't really a thing you could use right now. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: PSA: epel-rpm-macros in EL5 mock buildroots
The releng folks managed to get to the bottom of this and fix the underlying issue, so epel5 mock builds should now have the epel-rpm-macros package available for your specfile de-crufting needs. And remember, epel-rpm-macros-5 with functioning %autosetup is now in testing. Should make it to stable in about nine days assuming it doesn't get karma. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: PSA: epel-rpm-macros in EL5 mock buildroots
> "DJ" == Dave Johansenwrites: DJ> To my knowledge mock for EL 5 has been broken for several months DJ> now: I've had no problems using it. I did rebuild all of EPEL5 at least ten times recently and while there were plenty of failures I'm pretty sure those failures were due to broken packages, not mock. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] PSA: epel-rpm-macros in EL5 mock buildroots
Something went wrong when epel-rpm-macros-5 was added to the EPEL5 buildroot such that it works fine in koji but isn't actually present when you build in mock. So if you were trying to de-cruft your specs and found that things weren't working as you expected when you did a mock build, that's why. Unfortunately the issue has turned out to be complicated since before this comps hadn't changed since 2012 and something has probably broken in an odd way. The rel-eng folks are looking into things. Note that this also appears to break yom groupinfo and the like for any EPEL5-related things. In the meantime, if you want to just work around this yourself, edit /etc/mock/epel-5-*.cfg and add "epel-rpm-macros" to config_opts['chroot_setup_cmd']. That will give you what koji has currently. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] %autosetup for EPEL5
I thought it was impossible. Then I thought it was merely impossible without some terrible hacking. But now, after a bit of inspiration in the shower this morning, I went ahead and implemented the complete %autosetup functionality for EPEL5. Currently built as epel-rpm-macros-5.3 but not yet pushed to testing. As always, I welcome any testing. If these epel-rpm-macro packages can get karma, folks could start using the things I'm adding sooner rather than two weeks from now. And if you want something added, please file a bugzilla ticket on the epel-rpm-macros package and I'll have a look. Since folks on IRC were curious as to how this is possible: rpm >= 4.6 (i.e. EL6 and newer) provides two tables in the lua namespace: patches and sources. %autosetup iterates over patches to work its patch application magic. If you can somehow provide the patches table in EL5's rpm, you can use the autosetup macros verbatim as far as I can tell. So I wrote some lua support functions to iterate over a range of possible %SOURCEX and %PATCHX macros and stick anything found into the appropriate table. One line added to the %autosetup definition calls this function and everything else works. The whole thing is in /etc/rpm/macros.zzz-epel in the %epel_macros_init() scaffolding and the %elf_setup_patches() function. By default it looks at all of %PATCH0 through %PATCH10, which takes an immeasurably small amount of time on my test VM. If you really want to use Patch3141527: or whatever, you can set %el5_patches_limit in your spec. This is all working and tested; it can even prep rpm.spec from current rawhide without problems. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: using epel-rpm-macros
> "SJS" == Stephen John Smoogenwrites: SJS> What bug? Sorry we really need to see some actual output and SJS> problems here to have an idea of what we are trying to tackle. I think he's referring to the fact that the SCL macros break if you try to do too much with other macros. I could probably fix them if I put enough time into it, but... they're really unpleasant under the hood. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: using epel-rpm-macros
And I just pulled two random package with EL6 branches, changed %doc to %license in the appropriate places, and built them in mock. Everything came out as expected (no build failures, and the license files are in with the rest of the documentation). So I unfortunately have no idea what might be going wrong for you. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: using epel-rpm-macros
> "DL" == Dave Lovewrites: DL> How is the epel-rpm-macros package supposed to work? I have DL> epel-rpm-macros-6-4 installed, which is up-to-date against DL> epel-testing, and is supposed to make %license work like %doc but DL> doesn't seem to have any effect. Well, it did appear to have an effect when I tested it. Can you provide your spec or let me know which package you're testing? - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
> "TK" == Toshio Kuratomiwrites: TK> The easiest thing to do if you want a single spec file for EPEL7 and TK> Fedora is to Requires: python-foo rather than python2-foo. Except that FPC would like to move away from this. That's the entire reason I've brought this up. Any implicit dependency on python2 should be made explicit, and the "un-python-versioned" packages shouldn't be used as dependencies unless the package really does not care which version it gets. TK> Adding extra packages has the detriment of increasing the metadata TK> size that has to be downloaded when depsolving. That is not really much of a concern in a universe where we have texlive. TK> 166 packages might not be so bad... Or as you say, just doing a few TK> high value ones like python2-setuptools might be the best of both TK> worlds, providing compatibility for the most common cases but not TK> adding significantly to the metadata. I'm actually just going to submit a review for a python2-setuptools dummy package to take care of the most annoying case. If someone really dislikes this idea enough to block that, then I guess I'll find out. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
> "P" == Peterwrites: P> I would be worried, though, that you'll have packages that were built P> against python that are now trying to pull in and possibly run on P> python2 unnecessarily, and possibly detrimentally if Red Hat suddenly P> decides to push python2 packages out. I can't imagine a situation where that would happen. Perhaps you could give an example which you believe I haven't provided an accounting already. P> It seems to me that if the package is going to be built against P> pythin then it should require python, if it has to be built against P> python2 then it should require python2. I'm not understanding the issue here. python _is_ python2 and that isn't going to change for RHEL7 within its lifetime unless Red Hat really does bizarre things, and then we'd adapt. I just don't see Red Hat going so significantly against established Fedora packaging guidelines here. (Any package that needs the python3 version of something absolutely must require python3-something. It will never be acceptable for it to depend on python-something and expect that to be python3.) P> In neither case does it seem prudent to be tricking packages into P> thinking that python is actually python2. I don't see how anything is being tricked anywhere. This is adding just one thing: allow you to access python-foo via the package name python2-foo so that we don't have to have ifdefs. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
> "JH" == James Hogarthwrites: JH> Do just to be clear from your wording you are talking about RHEL JH> python packages that are known as python-foo in RHEL rather than JH> python2-foo there, since there is no other python within base to JH> cause confusion? Right, there are 166 such packages. And the issue isn't the name of those packages; it's whether you can expect to have some dependency on python2-foo satisfied on both Fedora and EPEL7. Fedora would like to start moving towards that in the near future. JH> Of course by guidelines python- on Fedora should be pointed at JH> python3- these days as that's the default runtime - correct? python3 is not the default runtime in any release of Fedora. (It's still python2 and will remain as such for the forseeable future.) The default runtime is defined as the target of the /usr/bin/python symlink. That's different from what we say about which version of Python a package should be using if it supports both. (That's python3.) The packaging guidelines don't indicate what packages should Require:. They don't really say what they should BuildRequires:, either, besides python2-devel or python3-devel. We are trying to move towards increasing stricture here, but first we wanted to mandate that everything actually Provides: python2-* first. Since we can't depend on RHEL ever doing that, any stricture we do introduce in the future will cause additional headache for EPEL packages. I'm just trying to head that off before it starts getting bad. JH> So these proposed would be not actually conflicting with base (no JH> python2- in base) but just sort of supplementing them to make JH> packaging EPEL python stuff easier on dependencies with less %if JH> {?el6} conditionals? Exactly. I obviously don't want to introduce any conflicts, and they're against the EPEL guidelines in any case. JH> How should this be maintained going forward into 7.3+ in case RH JH> bring more into base... They would be removed. If we set the version of the dummy package to zero, they won't even get in the way if a RHEL package does start providing python2-whatever, since the RHEL version would then always take precedence. JH> Unless you want to handle checking each milestone for fresh JH> python packages to dummy? Yes, that was the scripting I mentioned. It's not particularly difficult to see which python-* packages currently provide python2-* and to compare those against the list of dummy packages we're providing. It's not tough to check regularly and this should be done even if any possible conflicts are harmless. JH> In principle I think it a worthwhile endeavour in practice I think JH> it might complicate bug reporting to the correct component (EPEL vs JH> RHEL and any future python packages missing it). Not sure how this is any different from anything with a similar name to something in EPEL. If there are any misreported issues, it's a pretty quick click to change the component. I don't really expect that this would cause much in the way of problems, though, since these packages would never show up in the deplist of any RHEL package, and they contain no files so any automatic bug reporting setup wouldn't involve them. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Virtual packages providing python2-*
One annoying difference between packaging for Fedora and EPEL7 (and probably older) is the fact that Python packages in Fedora are required to provide "python2-foo" whereas many EL7 packages don't. This leads to ifdefs and unpleasantness, and kind of complicates our ability to hide some details behind macros. As I see it, the easiest way to hide this (besides RH maintainers updating those packages with the extra Provides:) is to add a bunch of empty packages named "python2-foo" which have nothing but a dependency on "python-foo". I can get a review process exception from FPC and script up the import of these things pretty trivially. The question is: would anyone object to this? Obviously we'll have to have some way of detecting any conflicts which might arise, which can be done pretty easily with some scripting. Even just getting python2-setuptools in would eliminate a lot of cruft. There are, I believe, 166 packages which might need this, though we don't have to add them all at once if that makes things more palatable. And if there's a need to discuss this at a meeting, could someone add it to the agenda (and remind me of the meeting time)? - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: How to go on with unmaintainable package?
> "CD" == Christian Derschwrites: CD> [...] for EPEL 6 I'm CD> unable to apply security fixes as one of them (the most important CD> one...) requires C++11 features not available in gcc 4.4 :( What is CD> the best strategy for such a package? Maybe ask someone who is really familiar with C++ to see if the change can be done in a way that's compatible with the older compiler? It should be quite possible to have a newer compiler in EPEL6 that's parallel-installable, but someone would have to actually do the work to make that happen. At least I don't think that violates any EPEL rules. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] %autosetup for EL6, epel-rpm-macros-6 license change
It appears that it's actually trivial to add %autosetup to RHEL6. You just need the Fedora macros plus a couple of extra definitions. That's in git now. I don't want to push this to testing because there's another version soaking in testing which I don't want to supersede. However, you can build from git and add it to a local repo if you want to test it out. Note that because I've copied the macros verbatim from Fedora, and those macros are basically the bulk of the package currently, I've just changed the license of epel-rpm-macros-6 to GPLv2+ (from GPLv2). What was previously in there was written by me so that shouldn't be an issue. Finally, it does not appear that this is possible on EL5 without a whole lot of magic, though I think I could make it work. If someone really wants %autosetup all the way down to EL5 then please let me know and I'll add it to my list. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Please test epel-rpm-macros 5-1 and 6-4
I should also note that epel-rpm-macros-6-2 has gone to stable, and it adds the requested node.js macro. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Please test epel-rpm-macros 5-1 and 6-4
The epel-rpm-macros-5-1 package for EPEL5 should now be in stable but I have not yet requested that it be added to the buildroot. This adds a number of things which I've mentioned earlier (Group:, BuildRoot: and %clean not needed; buildroot automatically cleaned in %install) and allows packagers to remove those bits from their specs if they want. This really needs to be tested. I've done local changes and done several mass builds and only found a couple of packages I need to investigate. Still, I don't know what might be out there and don't want to break anyone's non-EPEL stuff. Please set up mock and try it out. (See below.) Similarly, epel-macros-6-4 is currently in testing. When doing the EP5 macros I found a far simpler and cleaner way to define %license. I also added a guard to disable it if the SCL macros are present. How to test: You need mock installed locally. For EL6, just make sure that the testing repo is enabled and that epel-rpm-macros-6-4 gets into your buildroots. For EL5, add epel-rpm-macros to config_opts['chroot_setup_cmd']. Then build as normally, and also try to remove the bits you should no longer need. For EL5, double check the description of the built packages. (I just do rpmdiff -i T against the version built without the macros.) Due to the way %clean is added, if an existing %clean section appears immediately after %description, a couple of lines can be tacked onto the resulting package description. It's very weird for anything besides %prep or a %package stanza to follow %description, though, and it doesn't break the package in any case. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Orphaned Packages in epel6 (2016-02-01)
> "o" == opensourcewrites: o> The following packages are orphaned and will be retired when they are o> orphaned for six weeks, [...] o> directfb orphan, kwizart, thias 17 weeks ago How does the retiring actually happen? I know it's a manual process, but is there a script that gets run or does someone just do a checkout and run fedpkg retire? - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL5 mass rebuild (2016-01-20, 179 failures)
> "RF" == Richard Fearnwrites: RF> My point was that you couldn't get it to build because there was no RF> libewf to build it against. There is now, because the RF> disktype/libewf update has finally been pushed. Cool, then I suppose it will all be cleaned up after the next push. I think I actually missed some packages on my first run (due to a dumb mistake when I set up my build scripts) so I'll do another run at some point in the near future. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Necessity of some old RPM constructs in EL5
> "PH" == Paul Howarthwrites: PH> does not. It's probably still there because people can't remember PH> whether it was EL-5 or EL-6 that removed the need for it, and left PH> it there to be on the safe side. That's good to know. I also think there's more than a fair amount of cargo cult spec writing going on. "I'll just copy this package that works. What's this %defattr thing? No idea, but it must be important; I'll just leave it there." This is why I'm spending so much time trying to clean these things up. Many packagers just don't understand why all of this random stuff shows up in a spec. I would like for far less random stuff to ever be in a spec. PH> Might these affect people doing short-circuit builds? That's never PH> been a part of my workflow so I've not come across any issues with PH> it. I do not believe so, since the final spec after macro expansion is just a normal spec. What's happening is really not that much different then what, say, the fontpackages macros do when they generate sections, or the way that debuginfo packages are generated now. However, if someone who actually does short-circuit builds could give me some things to try, I'd be more than happy to do some testing. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Necessity of some old RPM constructs in EL5
> "DJ" == Dave Johansenwrites: DJ> And it's not helped by the fact that the version of rpmlint on EL 5 DJ> and 6 warns when it's missing. Interesting. Well, we can fix rpmlint. And I can grep at least the rawhide specfiles for remaining instances, generate a report, and eventually get them cleaned up. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL5 mass rebuild (2016-01-20, 179 failures)
> "DC" == Dan Callaghanwrites: DC> All of these broken dependencies onto python-setuptools-devel seemed DC> a little strange to me so I dug into it. Thanks for doing this. I thought it was a bit odd but figured it was better to actually get the report out there rather than try and figure out why everything was breaking. DC> So it seems like we will just need to update all those broken EPEL5 DC> packages to require python-setuptools instead of DC> python-setuptools-devel. Hopefully there are no interfaces (or DC> fixes) in the newer 0.6c9 version which EPEL packages were relying DC> on... Well, we can't really make the situation worse, can we? The alternative is simply to remove them, I guess. Anyway, any provenpackagers up for fixing these? I could script it, I guess, but I should give folks a chance to fix things up on their own. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Necessity of some old RPM constructs in EL5
I'm now working on some magic macros for EPEL5. Currently (on my machine, at least) you can use %license and don't need BuildRoot:. I'm curious about some other boilerplate constructs, though. %defattr in %files: I've been told that even EPEL5 doesn't need this, but still it persists. Can someone verify that it really is not required? Why do people keep putting it in if so? Cleaning %buildroot in %install:: Why is is so essential that the buildroot be cleaned as the first line of %install? I think I can make this happen magically but I'm not sure why it's needed at all. %clean What actually goes wrong if %clean isn't there? If it's just some cruft that might be left over after a successful build, then is it really an issue if it's not present? - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Adding epel-rpm-macros to the buildroot
> "DG" == Dennis Gilmorewrites: DG> When you are ready for the change to be made, please file a ticket DG> with releng, we will need to coordinate a koji and comps change. Yep, that was part of my plan. After committing the tiny fixes needed for those few packages (many of which hadn't been touched since the dist-git conversion) and a final complete rpmdiff run to make trebly certain that everything is OK, I've filed the releng ticket. Now I'll do the same checking for the version Orion committed that has the added nodejs macro, and work on adding others in the TODO list. Then its on to EPEL5. BTW, you can see the TODO list at https://pkgs.fedoraproject.org/cgit/rpms/epel-rpm-macros.git/tree/TODO?h=el6 Obviously some of those aren't actually possible, but it's worth a try. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] EPEL5 mass rebuild (2016-01-20, 179 failures)
I performed a mass build of EPEL5, skipping only a few packages that take absolutely forever to build (libguestfs, thunderbird-lightning, ikarus and pypy). I also skipped rubygem-eventmachine because its test suite hangs forever. Turns out that I should also have skipped perl-Gearman-Client-Async for the same reason, but I didn't, so it appears as a failure. Logs from all build failures are available at https://www.math.uh.edu/~tibbs/fedora As a fun note, I found that python-boto, python-six and python-requests are all in the repository, but have nobody with commit access to the EPEL5 branches. pkgdb has main contacts listed who have no access to the packages. That's why the list below shows no owners for them. For example, see: https://admin.fedoraproject.org/pkgdb/package/rpms/python-boto Total build failures: 179 Failures due to missing dependencies: 122 arprec-2.2.18-1.el5.src.rpm [qd-devel] (besser82) babel-0.9.5-2.el5.src.rpm [python26-distribute] (jcollie, fschwarz) Cython-0.14.1-3.el5.src.rpm [python26-distribute] (stevetraylen) dinotrace-9.4c-1.el5.src.rpm [emacs-verilog-mode] (chitlesh) disktype-9-5.el5.src.rpm [libewf-devel] (richardfearn, kwizart) euca2ools-2.1.3-1.el5.src.rpm [python26-setuptools] (gholms) gdal-1.4.2-4.el5.src.rpm [xerces-c-devel] (devrim, pali, volter) grin-1.1.1-3.el5.src.rpm [python-setuptools-devel] (hubbitus) mnemosyne-1.2.1-1.el5.src.rpm [python-setuptools-devel] (rathann) mongodb-1.6.4-1.el5.src.rpm [unittest] (npmccallum, tdawson, maxamillion, jpacner, hhorak, mskalick) mysql-connector-java-5.1.12-2.el5.src.rpm [ant-contrib >= 1.0] (stevetraylen, mjakubicek, jdornak, hhorak) perl-XML-Xerces-2.7.0_0-4.el5.src.rpm [xerces-c-devel = 2.7.0] (xavierb) planet-2.0-20.el5.src.rpm [python-setuptools-devel] (limb) pymol-1.1-14.20081015svn3468.el5.src.rpm [python-setuptools-devel] (timfenn, limb) pypar-2.1.0_66-3.el5.src.rpm [python-setuptools-devel] (bstinson) python26-argparse-1.2.1-3.el5.src.rpm [python26-distribute] (pingou) python26-boto-2.27.0-1.el5.src.rpm [python26-setuptools] (gholms) python26-cheetah-2.4.4-3.el5.src.rpm [python26-distribute] (stevetraylen) python26-eventlet-0.9.9-1.el5.src.rpm [python26-distribute] (kevin) python26-greenlet-0.3.1-3.el5.src.rpm [python26-distribute] (kevin) python26-markupsafe-0.11-3.el5.src.rpm [python26-distribute] (stevetraylen) python26-msgpack-0.1.12-2.el5.src.rpm [python26-distribute] (herlo) python26-mysqldb-1.2.3-2.el5.src.rpm [python26-distribute] (stevetraylen) python26-paramiko-1.7.7.1-1.el5.src.rpm [python26-setuptools] (arg, gholms) python26-PyXML-0.8.4-23.el5.src.rpm [python26-distribute] (stevetraylen) python26-PyYAML-3.08-4.el5.src.rpm [python26-setuptools] (herlo) python26-requests-0.13.1-1.el5.src.rpm [python26-distribute] (limb, sagarun) python-amqpclt-0.5-1.el5.src.rpm [rabbitmq-server] (mpaladin, lcons) python-application-1.1.5-1.el5.src.rpm [python-setuptools-devel] (peter) python-backports-ssl_match_hostname-3.4.0.2-5.el5.src.rpm [python26-distribute] () python-batchhttp-1.0-1.el5.src.rpm [python-setuptools-devel] (puiterwijk) python-boto-1.9b-6.el5.src.rpm [python-setuptools-devel] () python-catwalk-2.0.2-1.el5.src.rpm [python-setuptools-devel] (lmacken) python-cement-0.8.18-4.el5.src.rpm [python-sphinx] (derks) python-chardet-2.0.1-2.el5.src.rpm [python26-distribute] (kushal, churchyard) python-cheetah-2.0.1-1.el5.src.rpm [python-setuptools-devel] (mikeb) python-decorator-2.2.0-1.el5.src.rpm [python-setuptools-devel] (ralph) python-decorator3-3.1.2-2.el5.1.src.rpm [python-setuptools-devel] (lmacken) python-decoratortools-1.7-1.el5.src.rpm [python-setuptools-devel] (lmacken) python-demjson-1.3-4.el5.src.rpm [python-setuptools-devel] (lmacken, thm) python-docutils-0.5-3.el5.src.rpm [python-setuptools-devel] (oddshocks, group::infra-sig) python-dtopt-0.1-3.el5.src.rpm [python-setuptools-devel] (ricky) python-eventlet-0.9.12-2.el5.src.rpm [python-sphinx] (abbot, kevin) python-feedcache-1.3-5.el5.src.rpm [python-setuptools-devel] (lmacken) python-feedparser-5.0.1-1.el5.src.rpm [python-setuptools-devel] (lmacken, mcepl) python-flup-1.0-2.el5.src.rpm [python-setuptools >= 0.6c6] (till, jdornak) python-formencode-1.2.2-2.el5.src.rpm [python-setuptools-devel] (lmacken, ralph) python-genshi-0.5.1-1.el5.src.rpm [python-setuptools-devel] (jcollie, fschwarz) python-googlevoice-0.5-1.el5.src.rpm [python-setuptools-devel] (jcollie) python-guppy-0.1.9-1.el5.src.rpm [python-setuptools-devel] (peter) python-halite-0.1.16-1.el5.src.rpm [python26-distribute] (terminalmage) python-httplib2-0.7.7-1.el5.src.rpm [python-setuptools-devel] (awjb, jspaleta, dchen) python-jinja2-2.2.1-4.el5.src.rpm [python-setuptools-devel] (lmacken, thm) python-Levenshtein-0.10.1-6.el5.src.rpm [python-setuptools-devel] (dwayne) python-libcloud-0.14.1-1.el5.src.rpm [python26-distribute] (dbruno, terminalmage) python-mako-0.3.4-1.el5.src.rpm [python-setuptools-devel] (lmacken, kylev, mcepl) python-markdown2-1.4.2-2.el5.src.rpm
[EPEL-devel] Adding epel-rpm-macros to the buildroot
I've now done many mass rebuilds both with and without epel-rpm-macros in the buildroot and have found exactly 31 failures which result from the presence of the macro package. This macro package enables, in EPEL6, the use of %license in the %files section of the spec without having to conditionally define it. Twenty-nine of these build failures are due to the use of %define instead of %global and are trivially fixed by making that replacement. One is due to having a macro in a "comment" which breaks because the macro is now multi-line. The final fail7ure is due to a recursive expansion resulting from the mistaken assumption that a macro will not be defined at a particular place. The latter two are fixed simply by doubling a single '%'. I have all of these fixed in my local git repo. I would like to do two things: 1) File a releng ticket to have epel-rpm-macros added to the EPEL6 buildroot, as it is with EPEL7. 2) Push my changes to the 31 outstanding packages, by committing the small changes required to the el6 branches in git, but not rebuilding anything. This allows current git to build, but if maintainers would prefer to commit those changes to rawhide and pull them down to el6 they can easily revert my changes. Does anyone have any objections to me doing either of these? If I can get the macro package into the buildroot then I can move on with adding some of the other requested macros. This should all be much easier with the rebuild infrastructure I have in place now. I can also move on to trying to help out EPEL5 as well. I'd really like to put this phase of the work to bed as soon as is feasible. The list of packages needing the minor tweaks is below. All just need %define -> %global except for qt5-qttranslations and tesseract which need a single doubled '%' each. electronics-menu (chitlesh) epylog (smooge, icon) geos (devrim) itcl (orion, krege) itk (orion, krege) iwidgets (orion, krege) pdsh (spstarr, dmlb2000) postgresql-plruby (devrim, hhorak, praiskup, jmlich) python-clientform (lmacken) python-ruledispatch (lmacken) python-tgext-crud (lmacken) python-tgfastdata (lmacken) python-TurboMail (lmacken, fschwarz) qt5-qttranslations (rdieter, than, jreznik, ltinkl, rnovacek, jgrulich, group::kde-sig) retrace-server (mtoman, jfilak) ruby-augeas (lutter, skottler, domcleal) rubygem-sqlite3-ruby (kanarip, stahnma) ruby-ldap (stahnma, stevetraylen) ruby-libvirt (stahnma, clalance) ruby-mysql (orion, kanarip) ruby-ncurses (isimluk) ruby-shadow (stahnma, tmz, skottler) snake (jlaska, wwoods) tcllib (krege) tcl-mysqltcl (renep) tcl-tcludp (spot) tcl-tktreectrl (spot) tesseract (karlik, smani) tkcon (sergiopr) xpa (sergiopr) zanata-python-client (dchen, jamesni, seanf, anishpatil, robyduck, pnemade) - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Which python3 versions to package for EPEL7?
> "TK" == Toshio Kuratomiwrites: TK> We would have been in a lot better place today if we had separate TK> packaging of python2 and python3 packages in Fedora so that they TK> were never in sync there but that's not something we can probably TK> change now Nothing has ever prevented a packager from keeping separate packages for different python versions, but people really want the "one spec file for everything" approach for whatever reason. And, to be fair, for many modules there really is no reason to separate the py2 and py3 versions since the code isn't any different. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Additional python34 components for epel7
> "DF" == Denis Fateyevwrites: DF> If we just could work "the same SRPMS name" problem around ;-) DF> Healthy repos with the master branch orphaned [1] may look a little DF> weird to users... That is not abnormal for EPEL-only packages, though. The dead.package file in master should simply indicate that the package is EPEL-only. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: epel-rpm-macros for EL6 (and EL5)
> "AT" == Antonio Trandewrites: AT> %{__global_ldflags} is another macro that it's not available in AT> EPEL6. It appears that gets exported as a shell variable in the scope of %build by %__build_pre, as well as being mentioned in the %cmake, %cmake_kde4, %qmake_qt4 and %configure macros. Though some of might not even be present at all in EL6, and %configure is a much simpler macro there. I would have to override any existing definitions of all of those, but as there's essentially no chance of Red Hat changing those five macros at this point in the EL6 life cycle I don't see that this would be much of an issue. Can you let me know where the lack of %__global_ldflags is causing problems? (Maybe an example spec or two?) Would it help if I just added it to %configure or would it need to go elsewhere as well? I'll add it to the list in any case. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: epel-rpm-macros for EL6 (and EL5)
> "JLT" == Jason L Tibbittswrites: JLT> Does that actually work on EL6? Looking at the spec, it seems obvious that it works on EL6. The package isn't branched for EL5 but if anyone knows if -Wl,-z,relro will work there than I'll add it there as well (once I get around to doing an EL5 package). Remember, anything that requires an ifdef on any EPEL release is a candidate for what I'm doing. Obviously some things just aren't going to be possible, at least with RPM macros alone, but I'm willing to try. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] epel-rpm-macros for EL6 (and EL5)
Lately I've been working on an EL6 branch of epel-rpm-macros with the goal of removing the need for some of the %ifdefs and line noise and such required if you want to have one spec which builds on Fedora and EL6. Right now it simply enables %license in the %files section (mapped to %doc as the current workaround does). Feel free to suggest additional macros and I'll add them to the todo list and implement them as time and the nature of rpm allows. Since having this package in the buildroot has the capacity to break things, I've done a complete rebuild with the macros in place, and of course that turned up unrelated issues. You can find the complete results in the message I sent to this list earlier today. Now, the problem: When this macro package is present in the buildroot, a spec using %define (not %global as recommended) for a macro and using that macro in the %files section will break. Generally the macro just ends up undefined when the %files section. Why? Deep RPM macro magic, I guess. Which is why we have long said that you should use %global unless you have a specific reason not to do so. This breakage troubles me, and I think it would be a deal breaker if we didn't already prohibit use of %define in the guidelines. There aren't many packages which have problems, though, and my testing hasn't turned up any problems that can't be attributed to the macros. Below is a list of packages which use %define in a way that causes build failures with the macros package. Fixing them up is completely trivial. I am happy to just take care of them, but I'll try to contact the maintainers first. - J< electronics-menu-1.0-8.el6.src.rpm chitlesh epylog-1.0.7-1.el6.src.rpm smoote, icon geos-3.3.2-1.el6.src.rpm devrim itcl-3.4-6.el6.src.rpm orion, krege itk-3.4-5.el6.src.rpm orion, krege iwidgets-4.0.2-4.el6.src.rpm orion, krege plplot-5.9.7-3.el6.1.src.rpm orion postgresql-plruby-0.5.3-4.el6.src.rpm devrim, hhorak, praiskup, jmlich python-clientform-0.2.7-6.el6.src.rpm lmacken python-ruledispatch-0.5a0-0.15.svnr2306.el6.src.rpm lmacken python-tgext-crud-0.3.11-1.el6.src.rpm lmacken python-tgfastdata-0.9a6-10.el6.src.rpm lmacken python-TurboMail-3.0-1.el6.src.rpm lmacken, fschwarz retrace-server-1.12-2.el6.src.rpm mtoman ruby-augeas-0.4.1-1.el6.src.rpm lutter, skottler, domcleal rubygem-sqlite3-ruby-1.2.4-5.el6.src.rpm kanarip, stahnma ruby-ldap-0.9.7-10.el6.src.rpm stahnma, stevetraylen ruby-libvirt-0.5.2-2.el6.src.rpm stahnma, clalance ruby-mysql-2.8.2-1.el6.src.rpm orion, kanarip ruby-ncurses-1.3.1-2.el6.src.rpm isimluk ruby-shadow-1.4.1-13.el6.src.rpm stahnma, tmz, skottler snake-0.11-0.20.el6.src.rpm jlaska, wwoods tcllib-1.14-1.el6.src.rpm krege tcl-mysqltcl-3.05-8.el6.src.rpm renep tcl-tcludp-1.0.8-3.el6.src.rpm spot tcl-tktreectrl-2.2.10-1.el6.src.rpm spot tesseract-3.04.00-1.el6.src.rpm karlik, smani tkcon-2.5-4.el6.src.rpm sergiopr xpa-2.1.12-1.el6.src.rpm sergiopr (I see tktable has been fixed in git already, and blt was fixed immediately after I filed a bugzilla ticket. Thanks!) ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Mass rebuild of EPEL6
> "AT" == Antonio Trandewrites: AT> This is not current tktable release. Well, it's what is currently on the master mirror. I'm not building from git; I'm taking the current set of released SRPMs. I could take them from testing instead if that's thought to be generally useful. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel]Re: python2-setuptools metapackage
> "DC" == Dan Callaghanwrites: DC> Would it be easier to request the RHEL packages to add a virtual DC> Provides for the python2-* name? That is, python-setuptools in RHEL DC> could provide python2-setuptools. I can't imagine Red Hat going through all of the bureaucracy to issue updates and creating that much churn for their customers to add a single Provide: to a number of packages when it could be trivially done on the EPEL side for the cost of a few empty packages. Of course, if those packages are going to rev anyway then it would certainly be nice if the extra provide could be added. The metapackage could disappear from EPEL at that point. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org