[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

[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:

[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

[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:

[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

[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

[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

[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

[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

[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

[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] 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

[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

[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

[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

[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

[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 Massullo writes: 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

[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

[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] 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):

[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

[EPEL-devel] Re: ansible1.9 package

> "SJS" == Stephen John Smoogen writes: 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

[EPEL-devel] Re: Stub python packages for EPEL

> "KF" == Kevin Fenzi writes: 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

[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

[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

[EPEL-devel] Re: Pull request/Changes to CentOS Extras repo??

> "SJS" == Stephen John Smoogen writes: 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

[EPEL-devel] Re: OFFLIST Re: rh-epel] END OF LIFE FOR EPEL-5 (2017-03-31)

> "RPH" == R P Herrold writes: 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

[EPEL-devel] Re: Major updates to nagios and nrpe

> "SJS" == Stephen John Smoogen writes: 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

[EPEL-devel] Re: NOTCE: Red Hat Enterprise Linux 5 Three-Month Retirement Notice

> "PR" == Peter Robinson writes: 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

[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

[EPEL-devel] Re: EPEL5 man page compression

> "RF" == Richard Fearn writes: 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

[EPEL-devel] Re: EPEL5 man page compression

> "RF" == Richard Fearn writes: 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

[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

[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

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

> "d" == dani writes: 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

[EPEL-devel] Re: python34 for EPEL6

> "AL" == Avram Lubkin writes: 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] Re: python34 for EPEL6

> "AL" == Avram Lubkin writes: 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

[EPEL-devel] Re: python34 for EPEL6

> "AL" == Avram Lubkin writes: 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

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

> "DJ" == Dave Johansen writes: 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

[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

[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

[EPEL-devel] Re: Simplifying use of Python 3 macros?

> "DJ" == Dave Johansen writes: 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

[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

[EPEL-devel] Re: PSA: epel-rpm-macros in EL5 mock buildroots

> "DJ" == Dave Johansen writes: 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

[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.

[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

[EPEL-devel] Re: using epel-rpm-macros

> "SJS" == Stephen John Smoogen writes: 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

[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

[EPEL-devel] Re: using epel-rpm-macros

> "DL" == Dave Love writes: 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.

[EPEL-devel] Re: Virtual packages providing python2-*

> "TK" == Toshio Kuratomi writes: 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.

[EPEL-devel] Re: Virtual packages providing python2-*

> "P" == Peter writes: 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

[EPEL-devel] Re: Virtual packages providing python2-*

> "JH" == James Hogarth writes: 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,

[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

[EPEL-devel] Re: How to go on with unmaintainable package?

> "CD" == Christian Dersch writes: 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

[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

[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

[EPEL-devel] Re: Orphaned Packages in epel6 (2016-02-01)

> "o" == opensource writes: 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,

[EPEL-devel] Re: EPEL5 mass rebuild (2016-01-20, 179 failures)

> "RF" == Richard Fearn writes: 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

[EPEL-devel] Re: Necessity of some old RPM constructs in EL5

> "PH" == Paul Howarth writes: 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

[EPEL-devel] Re: Necessity of some old RPM constructs in EL5

> "DJ" == Dave Johansen writes: 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

[EPEL-devel] Re: EPEL5 mass rebuild (2016-01-20, 179 failures)

> "DC" == Dan Callaghan writes: 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

[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

[EPEL-devel] Re: Adding epel-rpm-macros to the buildroot

> "DG" == Dennis Gilmore writes: 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

[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

[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

[EPEL-devel] Re: Which python3 versions to package for EPEL7?

> "TK" == Toshio Kuratomi writes: 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

[EPEL-devel] Re: Additional python34 components for epel7

> "DF" == Denis Fateyev writes: 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

[EPEL-devel] Re: epel-rpm-macros for EL6 (and EL5)

> "AT" == Antonio Trande writes: 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

[EPEL-devel] Re: epel-rpm-macros for EL6 (and EL5)

> "JLT" == Jason L Tibbitts writes: 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

[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

[EPEL-devel] Re: Mass rebuild of EPEL6

> "AT" == Antonio Trande writes: 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

[EPEL-devel]Re: python2-setuptools metapackage

> "DC" == Dan Callaghan writes: 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