Re: Automatic Provides: Discussion summary and plan

> "PV" == Petr Viktorin writes: PV> * One macro for getting the canonical (normalized) dist-name: PV> %{python_dist_name NAME} Do you mean "setting" here? PV> * Four macros for adding Requires and BuildRequires lines (which use PV> the python_dist_name macro

Re: Automatic Provides: Discussion summary and plan

> "TO" == Tomas Orsava writes: TO> That looks incredible! Why didn't it see the light of day? Time TO> constraints or some technical issues? Well, it sort of fell by the wayside as I got involved with other things. I've learned a lot about RPM internals since then and I

Re: Automatic Provides: Discussion summary and plan

> "PV" == Petr Viktorin writes: PV> No, getting. Example expansion: PV> %{python_dist_name ndg_HTTPSclient} => ndg-httpsclient Ah, OK, that makes much more sense. PV> Would "python3_requires" and "python3_buildrequires" be better? I think so. PV> Please do and share

[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

Re: [Guidelines change] Changes to the packaging guidelines

Oops, one additional change was made which I left out of the previous announcement. A section was added to the Python guidelines describing the automatic generation of Provides: which was added in Fedora 25. Descriptions of three new macros were also added. *

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - The systemd section of the scriptlet guidelines was updated to indicate situations where the %systemd_ordering macro may be used instead of %systemd_requires. * https://fedoraproject.org/wiki/Packaging:Scriptlets#Systemd *

Re: Automatic Provides: Discussion summary and plan

> "PV" == Petr Viktorin writes: PV> - Make it standard practice in Fedora to use this data and treat the PV> spec file as an immutable generated artifact. If you're saying that any changes which are made to the spec file (say, by release engineering doing a rebuild or

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

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

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

Removal of the default 16 job limit for makefile parallelism

The hardcoded upper limit of 16 jobs, passed to make via "-j" when you use either %make_build or make %{?_smp_mflags} in the %build section of your specfiles, is going away in rawhide. This may result in your jobs being run with additional parallelization in some situations. This change will

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

Re: Finalizing Fedora's Switch to Python 3

> "MH" == Miro Hrončok writes: MH> I just had a discussion with Tomáš Orsava and Petr Viktorin on MH> #fedora-python. Rather than asking FESCo now to allow mass MH> fully-automated spec changing, we'll open bugs as planned, but we'll MH> attach patches generated by your

[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

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

> "IS" == Iryna Shcherbina writes: IS> Thanks a lot, that is helpful. There is also a pkgdb2client [0] IS> package that I've been looking into for this. You could run that tool in a loop, parse the result and generate the report, I guess, but it's also rather trivial to

Re: flit

> "TK" == Toshio Kuratomi writes: TK> However, you should check with tibbs/FPC about TK> whether the definitions/list of macros are an altogether dated TK> concept. I think it's reasonable to document macros which are going to need to use. Python packaging just isn't

[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

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - Many changes have been made to the Ruby packaging guidelines to reflect the current state of Ruby packaging. * https://fedoraproject.org/wiki/Packaging:Ruby * https://pagure.io/packaging-committee/issue/710 Note that the macros

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

Python2 stub packages now in EPEL stable

[For those who don't read epel-devel, this is a duplicate of a message also posted there.] 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

[Guidelines change] Changes to the packaging guidelines

Just this one change, but it has implications for many packages. The Scriptlet guidelines have received several changes regarding the installation of shared libraries and ldconfig. Use of the new macros is detailed, and there is a new section on the scriptlets required when linker configuration

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

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - The packaging guidelines for enabling services by default were significantly revised to emphasize that services starting by default should fail only in exceptional conditions, and to provide additional guidance for services related

[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

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - A note was added to the Python guidelines indicating that the python2 stack may go away and that upstreams should be contacted about software not yet ported to python3. *

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

Re: Draft: Macros to tell what Python versions to package for

> "MH" == Miro Hrončok writes: MH> I expect it to be called for both 2 and 3 unconditionally. Hiding MH> the condition in the maro makes things too magical for me. I don't think that stance holds up well as we increasingly hide things in macros and will continue to hide

Re: Draft: Macros to tell what Python versions to package for

> "PV" == Petr Viktorin writes: PV> %install PV> %install PV> %if %{with python2} PV> %py2_install PV> %endif PV> %if %{with python3} PV> %py3_install PV> %endif So... why not just make %py2_install and %py3_install just do the %{with python*} internally, so the

Re: What is the criterion for Python 3.7 side tag merge?

> "MH" == Miro Hrončok writes: MH> What is the criterion to merge the side tag? I think ultimately that's up to you, but certainly the idea is to balance disruption (breaking builds or rawhide usability) against holding back progress (the approved python 3.7 feature). It would certainly be

Re: [EPEL-devel] 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: 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: 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

Re: [EPEL-devel] 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] 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

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - We have begun to remove content from the wiki. The old pages should all now have links to the new docs site. As we continue to work on the new documents, the corresponding wiki pages will be emptied and left only with the link to

Re: Removal of Python 2 from the Xfce spin

> "MH" == Miro Hrončok writes: MH> Aaaand... it's reverted :D He reverts any of the commits I have made to the packages he maintains as well. Just mass cleanup things like the removal of defattr. Reverted with a completely empty commit message. I really don't want to get into a revert war

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - The Python packaging guidelines have been updated to reflect the fact that Python 2 is deprecated. All relevant information for legacy Python 2 packaging has been moved to the appendix. Together with this change, the rule for

Re: Python 2 Package Removal and when to use fedora-obsolete-packages

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> Heh, I don't think the FPC policy is very robust. It's as robust as is reasonable to implement. When fedora-obsolete-packages was introduced, there was considerable controversy over whether it is remotely acceptable to remove installed

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

Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

> "MH" == Miro Hrončok writes: MH> Are my assumptions correct? Yes, unless some major changes happened of which I was not aware, you cannot have any package name in EPEL7 (including a source package) which duplicates a package name in RHEL7 _on a particular architecture_. (There are

[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

Re: django-pytest vs pytest-django

> "DM" == David Moreau-Simard writes: DM> I don't have the bandwidth to take care of pytest-django right now. DM> Would it be acceptable to propose a new package without %check until DM> it gets packaged ? It's OK to disable tests you can't run because they have additional dependencies

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

<    2   3   4   5   6   7