On Sun, Dec 13, 2020 at 10:37:49AM -0700, Orion Poplawski wrote:
> On 12/11/20 5:04 PM, Miro Hrončok wrote:
> > On 12/12/20 12:12 AM, Troy Dawson wrote:
> > > There is also a problem if a missing package has been specifically
> > > blocked by a module. I think libuv-devel is this way.
> >
> > If
On Tue, Dec 15, 2020 at 5:06 AM Andrew C Aitchison
wrote:
>
> On Tue, 15 Dec 2020, Miro Hrončok wrote:
>
> > On 12/13/20 7:52 PM, Andrew C Aitchison wrote:
> >>
> >> On Sun, 13 Dec 2020, Miro Hrončok wrote:
> >>
> >>> Also, since you might want to bump the release independently in EPEL (e.g.
>
On Tue, 15 Dec 2020, Miro Hrončok wrote:
On 12/13/20 7:52 PM, Andrew C Aitchison wrote:
On Sun, 13 Dec 2020, Miro Hrončok wrote:
Also, since you might want to bump the release independently in EPEL (e.g.
if we discover something was wrong in the way we have packaged this), I
recommend
On 12/13/20 7:52 PM, Andrew C Aitchison wrote:
On Sun, 13 Dec 2020, Miro Hrončok wrote:
Also, since you might want to bump the release independently in EPEL (e.g. if
we discover something was wrong in the way we have packaged this), I recommend
doing:
%global rhelrelease 10
%global
On 12/13/20 7:21 PM, Stephen John Smoogen wrote:
Don't forget to move the following metadata to the main package:
Summary: Development files for QPDF library
Requires: qpdf-libs%{?_isa} = %{version}-%{release}
Do you mean the main package as qpdf ? We don't control that
On Sun, 13 Dec 2020, Miro Hrončok wrote:
Also, since you might want to bump the release independently in EPEL (e.g. if
we discover something was wrong in the way we have packaged this), I
recommend doing:
%global rhelrelease 10
%global baserelease 1
Release:
On Sun, 13 Dec 2020 at 13:17, Miro Hrončok wrote:
> On 12/13/20 7:03 PM, Orion Poplawski wrote:
> > On 12/13/20 10:37 AM, Orion Poplawski wrote:
> >> On 12/11/20 5:04 PM, Miro Hrončok wrote:
> >>> On 12/12/20 12:12 AM, Troy Dawson wrote:
>
> > Seem reasonable? I was able to install the
On 12/13/20 7:03 PM, Orion Poplawski wrote:
On 12/13/20 10:37 AM, Orion Poplawski wrote:
On 12/11/20 5:04 PM, Miro Hrončok wrote:
On 12/12/20 12:12 AM, Troy Dawson wrote:
We discussed this in the EPEL Steering Committee this week, and your
way has alot less "mess with the server and modules"
On 12/13/20 10:37 AM, Orion Poplawski wrote:
On 12/11/20 5:04 PM, Miro Hrončok wrote:
On 12/12/20 12:12 AM, Troy Dawson wrote:
We discussed this in the EPEL Steering Committee this week, and your
way has alot less "mess with the server and modules" work.
It would probably get us up to 75% of
On Sun, 13 Dec 2020 at 12:38, Orion Poplawski wrote:
> On 12/11/20 5:04 PM, Miro Hrončok wrote:
> > On 12/12/20 12:12 AM, Troy Dawson wrote:
> >> There is also a problem if a missing package has been specifically
> >> blocked by a module. I think libuv-devel is this way.
> >
> > If that
On 12/11/20 5:04 PM, Miro Hrončok wrote:
On 12/12/20 12:12 AM, Troy Dawson wrote:
There is also a problem if a missing package has been specifically
blocked by a module. I think libuv-devel is this way.
If that happens, wouldn't it be blocked in both scenarios
(module+grobisplitter+tagging
On 12/12/20 12:12 AM, Troy Dawson wrote:
At the end a package called qgpgme-devel will be built in EPEL and available in
the EPEL buildroot despite the fact that there is a qgpgme-devel package in RHEL
buildroot.
Since the only reason we don't allow this already is policy, why don't we amend
On Fri, Dec 11, 2020 at 1:44 PM Miro Hrončok wrote:
>
> On 12/11/20 7:42 PM, Troy Dawson wrote:
> > Our current solution for the missing RHEL8 devel packages is going away.
> > And let's be honest, it was only about 50% successful. We needed
> > something else anyway.
> >
> > Here is my proposal
On 12/11/20 7:42 PM, Troy Dawson wrote:
Our current solution for the missing RHEL8 devel packages is going away.
And let's be honest, it was only about 50% successful. We needed
something else anyway.
Here is my proposal for a new solution.
Be warned, this proposal has words like module, and
14 matches
Mail list logo
