[EPEL-devel] EPEL and the new distribution-related macros

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

> 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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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?

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

(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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

> "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 mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: python34 for EPEL6

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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?

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

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

[Jason L Tibbitts III]

> "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.  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-*

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

> "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, 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-*

[Jason L Tibbitts III]

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?

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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)

[Jason L Tibbitts III]

> "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,
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)

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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?

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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

[Jason L Tibbitts III]

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