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<
Show replies by date
On Tue, Jan 19, 2016 at 11:02 PM, Jason L Tibbitts III <tibbs(a)math.uh.edu>
wrote:
Does anyone have any objections to me doing either of these?
I think this is great, and thanks for your work on it.
-Jeff
On Wed, 20 Jan 2016 01:02:46 -0600
Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
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.
...snip...
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.
Sounds great to me, and thanks for working on this. :)
kevin
On Wednesday, January 20, 2016 08:26:13 AM Kevin Fenzi wrote:
On Wed, 20 Jan 2016 01:02:46 -0600
Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
> 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.
...snip...
> 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.
Sounds great to me, and thanks for working on this. :)
kevin
+1
When you are ready for the change to be made, please file a ticket with
releng, we will need to coordinate a koji and comps change.
Dennis
>>>> "DG" == Dennis Gilmore
<dennis(a)ausil.us> 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<