using epel-rpm-macros

[Dave Love]

How is the epel-rpm-macros package supposed to work?  I have
epel-rpm-macros-6-4 installed, which is up-to-date against epel-testing,
and is supposed to make %license work like %doc but doesn't seem to have
any effect.  I get the same errors using %license in %files as without
it installed ("error: File must begin with "/": GPLv3" etc.).  What else
do I need to do?

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

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

[Dave Love]

Jason L Tibbitts III  writes:
> 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<

In preparing the recipe with the minimal spec to demonstrate, I realized
it's because it doesn't work if you have scl build stuff installed.  I
wonder if it would be better -- at least more obvious! -- to have it
conflict with the scl macros package.

Will the scl bug mentioned not be fixed?

[Stephen John Smoogen]

On 25 March 2016 at 10:46, Dave Love  wrote:
> Jason L Tibbitts III  writes:
> > 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<
>
> In preparing the recipe with the minimal spec to demonstrate, I realized
> it's because it doesn't work if you have scl build stuff installed.  I
> wonder if it would be better -- at least more obvious! -- to have it
> conflict with the scl macros package.
>
> Will the scl bug mentioned not be fixed?

What bug? Sorry we really need to see some actual output and problems
here to have an idea of what we are trying to tackle.
> epel-devel mailing list
> [e-mail]
> http://lists.fedoraproject.org/admin/lists/[e-mail]...

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

[Jason L Tibbitts III]

> > > > > "DL" == Dave Love  writes:

DL> In preparing the recipe with the minimal spec to demonstrate, I
DL> realized it's because it doesn't work if you have scl build stuff
DL> installed.

Yep, it explicitly gets out of the way if the SCL stuff is there.  This
is to avoid bugs in the SCL macros.

DL> I wonder if it would be better -- at least more obvious!
DL> -- to have it conflict with the scl macros package.

That would be absolutely terrible, not to mention forbidden by the
packaging guidelines.  Since epel-rpm-macros is in the buildroot, this
would render it impossible to build SCL packages in mock or copr or
whatever.

If you have a build dependency on the SCL tools then you're obviously
not building for EPEL, and building locally doesn't necessarily ever
give you the same behavior as building in mock, so...

The best I could do is emit some kind of warning, but I'm not sure
that's even worth it.  The behavior is documented in the actual macro.

DL> Will the scl bug mentioned not be fixed?

That would be up to whoever maintains the SCL macros.  They are very
fragile and can't handle even the single simple redifinition that makes
%license to work.  They're written in a way that makes it obvious that
someone was just trying to get something which did what they want, not
trying to make something which is readable or understandable.

- J<

[Dave Love]

Jason L Tibbitts III 
writes:
> If you have a build dependency on the SCL tools then you're obviously
> not building for EPEL,

Well, I'm building for people running EPEL, and I didn't see this isn't
with packages that depend on anything scl.  The scl stuff needs to be
installed initially, e.g. in copr root parameters, if you're going to
build scl packages at some stage.

(I don't understand why software collections aren't allowed so that more
packages could be contributed.)
> DL> Will the scl bug mentioned not be fixed?
>
> That would be up to whoever maintains the SCL macros.

Of course.  I was thinking in terms of (lack of?) response to a bug
report which might get someone to look to it.

[Dave Johansen]

On Sun, Mar 27, 2016 at 7:52 AM, Dave Love  wrote:
> Jason L Tibbitts III 
> writes:
> > If you have a build dependency on the SCL tools then you're obviously
> > not building for EPEL,
>
> Well, I'm building for people running EPEL, and I didn't see this isn't
> with packages that depend on anything scl.  The scl stuff needs to be
> installed initially, e.g. in copr root parameters, if you're going to
> build scl packages at some stage.
>
> (I don't understand why software collections aren't allowed so that more
> packages could be contributed.)

Inclusion of SCLs has been discussed several times and there's just never
been a way to make it work. If I recall correctly, Fedora still doesn't
allow SCLs as well.

[James Hogarth]

On 27 Mar 2016 15:58, "Dave Johansen"  wrote:
> On Sun, Mar 27, 2016 at 7:52 AM, Dave Love  wrote:
> > Jason L Tibbitts III 
> > writes:
> > > If you have a build dependency on the SCL tools then you're obviously
> > > not building for EPEL,
> >
> > Well, I'm building for people running EPEL, and I didn't see this isn't
> > with packages that depend on anything scl.  The scl stuff needs to be
> > installed initially, e.g. in copr root parameters, if you're going to
> > build scl packages at some stage.
> >
> > (I don't understand why software collections aren't allowed so that more
> > packages could be contributed.)
>
> Inclusion of SCLs has been discussed several times and there's just never

been a way to make it work. If I recall correctly, Fedora still doesn't
allow SCLs as well.
>

Which is a pity to a certain extent as it's the dependency issue of old php
that will prevent an updated owncloud in EPEL6 now that I've looked into it
more. We have to retire it there (though I may add a personal SCL based
copr for it with the caveat I suggest people move to EL7).

[Stephen John Smoogen]

On 27 March 2016 at 08:52, Dave Love  wrote:
> Jason L Tibbitts III 
> writes:
> > If you have a build dependency on the SCL tools then you're obviously
> > not building for EPEL,
>
> Well, I'm building for people running EPEL, and I didn't see this isn't
> with packages that depend on anything scl.  The scl stuff needs to be
> installed initially, e.g. in copr root parameters, if you're going to
> build scl packages at some stage.
>
> (I don't understand why software collections aren't allowed so that more
> packages could be contributed.)

You are running into one of the issues about why they weren't allowed
in base Fedora. This isn't the only macro problem that has come up and
while they each get eventually dealt with by the SCL guys.. it is a
whack-a-mole game...
> > DL> Will the scl bug mentioned not be fixed?
> >
> > That would be up to whoever maintains the SCL macros.
>
> Of course.  I was thinking in terms of (lack of?) response to a bug
> report which might get someone to look to it.
> _______________________________________________
> epel-devel mailing list
> [e-mail]
> http://lists.fedoraproject.org/admin/lists/[e-mail]...

Compiz

[john tatt]

Hi guysis there a chance to get someday compiz for Centos7 in Epel ?
thanks