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?
"DL" == Dave Love d.love@liverpool.ac.uk 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<
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<
Jason L Tibbitts III tibbs@math.uh.edu 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?
On 25 March 2016 at 10:46, Dave Love d.love@liverpool.ac.uk wrote:
Jason L Tibbitts III tibbs@math.uh.edu 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 epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.or...
"SJS" == Stephen John Smoogen smooge@gmail.com 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<
"DL" == Dave Love d.love@liverpool.ac.uk 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<
Jason L Tibbitts III tibbs-6Fsk2Ie8wHGVc3sceRu5cw@public.gmane.org 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.
On Sun, Mar 27, 2016 at 7:52 AM, Dave Love d.love@liverpool.ac.uk wrote:
Jason L Tibbitts III tibbs-6Fsk2Ie8wHGVc3sceRu5cw@public.gmane.org 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.
On 27 Mar 2016 15:58, "Dave Johansen" davejohansen@gmail.com wrote:
On Sun, Mar 27, 2016 at 7:52 AM, Dave Love d.love@liverpool.ac.uk wrote:
Jason L Tibbitts III tibbs-6Fsk2Ie8wHGVc3sceRu5cw@public.gmane.org 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).
On 27 March 2016 at 08:52, Dave Love d.love@liverpool.ac.uk wrote:
Jason L Tibbitts III tibbs-6Fsk2Ie8wHGVc3sceRu5cw@public.gmane.org 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 epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.or...
Hi guysis there a chance to get someday compiz for Centos7 in Epel ? thanks
epel-devel@lists.fedoraproject.org
-
Dave Johansen -
Dave Love -
James Hogarth -
Jason L Tibbitts III -
john tatt -
Stephen John Smoogen