On Tue, Aug 15, 2017 at 12:01 PM, Simone Caronni
wrote:
>
> If I trigger the rebuild in Koji, we will get again the same version as
> the first one.
>
What will the CentOS folks do for these rebuilds?
Regards,
--Simone
--
You cannot discover new oceans unless you have the cou
On Tue, Aug 15, 2017 at 11:38 AM, Simone Caronni
wrote:
> On Fri, Aug 11, 2017 at 8:00 PM, Stephen John Smoogen
> wrote:
>>
>> The remaining packages which are not in all architectures BUT are very
>> old (and may break other things). These need some sort of up
On Fri, Aug 11, 2017 at 8:00 PM, Stephen John Smoogen
wrote:
>
> The remaining packages which are not in all architectures BUT are very old
> (and may break other things). These need some sort of update/rebuild I
> expect.
>
> libssh
> libtomcrypt
> libtommath
> libvncserver
>
Will check those fo
Hello,
a package entered stable that overwrites part of a RHEL 7 package.
The bug is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1396841
As originally reported, the contributor has not replied in 10 days so
I'm reporting the thing here. I would consider this an urgent bug; as
it's impossi
On 15 May 2015 at 12:03, Paul Howarth wrote:
>
> Looks to me like that sub-package has an arch-specific dependency but it's
> a noarch sub-package.
>
Gotcha. Thanks for spotting!!
Does not create any problem if you install from the same mock build as the
dependency will be stuck on the same arc
27;ve
seen this message.
Regards,
--Simone
On 15 May 2015 at 10:46, Simone Caronni wrote:
> On 15 May 2015 at 10:42, Simone Caronni wrote:
>
>> Hello,
>>
>> don't know if it has been reported already, but I have 3 weird errors on
>> Koji while scratch
On 15 May 2015 at 10:42, Simone Caronni wrote:
> Hello,
>
> don't know if it has been reported already, but I have 3 weird errors on
> Koji while scratch building some packages. Please note that last time the
> same packages built fine.
>
> - el5 ignores debug files
Hello,
don't know if it has been reported already, but I have 3 weird errors on
Koji while scratch building some packages. Please note that last time the
same packages built fine.
- el5 ignores debug files and does not assemble the debuginfo package (?):
http://koji.fedoraproject.org/koji/taski
On 17 March 2015 at 20:08, Paul Howarth wrote:
> On Tue, 17 Mar 2015 11:34:10 -0600
> Stephen John Smoogen wrote:
>
> > This was on the packaging list but effects EPEL. Any suggestions?
> >
> > -- Forwarded message --
> > From: Thomas Moschny
> > Date: 17 March 2015 at 10:59
> >
Hello,
I'm going to fix this ASAP. Had a busy week and catched up with mails just
now.
Please leave some karma feedback after testing.
BTW, this list is not the correct place to post this kind of requests,
please open a bug on the selected component.
Regards,
--Simone
On 9 October 2014 01:00,
On 8 July 2014 05:12, Kevin Fenzi wrote:
> Anyone have anything else for the list?
>
Update the mock configuration files in the mock package!
Thanks & regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/2
Ok, thanks for the multiple explanations :)
On 17 June 2014 16:27, Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tue, 17 Jun 2014 16:14:55 +0200
> Simone Caronni wrote:
>
> > On 17 June 2014 16:07, Jeff Sheltren wrote:
> >
>
On 17 June 2014 16:07, Jeff Sheltren wrote:
> On Tue, Jun 17, 2014 at 12:23 AM, Simone Caronni
> wrote:
>
>>
>>
>> Aren't we already using CentOS for EPEL 5 and 6 in the koji/mock
>> buildroots? 32 bit aside, what is the difference for 7?
>> This h
Hello,
thanks for your answers.
On 17 June 2014 00:59, Jim Perrin wrote:
> > By using CentOS as the basis and not RHEL 7 we could have all the
> channels
> > that are not used at the moment for building.
>
>
> As much as I'd like to see CentOS as the basis for *everything* (I may
> be a bit bia
On 16 June 2014 21:29, Kevin Fenzi wrote:
> On Mon, 16 Jun 2014 21:12:57 +0200
> Simone Caronni wrote:
>
> >
> > Another thing, there are packages that are spread into multiple
> > upstream optional channels that make it impossible to include some
> > packages
On 16 June 2014 21:28, Kevin Fenzi wrote:
> On Mon, 16 Jun 2014 21:03:57 +0200
> Simone Caronni wrote:
> > CentOS 7 is being built also for i386 and that would
> > mean a lot of semplification into adding packages in EPEL 7. Right
> > now the situation is a bi
On 16 June 2014 21:03, Simone Caronni wrote:
> On 16 June 2014 20:15, Kevin Fenzi wrote:
>
>> * When do we want to look at leaving beta status for epel7?
>> I'd suggest we should definitely give CentOS time to release, but
>> should we have any other critera?
>&
Hello,
On 16 June 2014 20:15, Kevin Fenzi wrote:
> * When do we want to look at leaving beta status for epel7?
> I'd suggest we should definitely give CentOS time to release, but
> should we have any other critera?
>
I would really, really like to have CentOS 7 available before the final
releas
On 4 June 2014 18:18, Till Maas wrote:
> On Wed, Jun 04, 2014 at 08:47:27AM -0600, Kevin Fenzi wrote:
>
> > We might want to hold off on limited arch packages until rhel7 is
> > actually released... since we don't really know whats in the final set
> > until it's there.
>
> Unless RHEL will not p
On 2 June 2014 16:46, T.C. Hollingsworth wrote:
> I'd suggest filing a bug in bugzilla first, explaining the pain this
> causes downstream addon repositories like EPEL. For all we know the
> -devel subpackage is only missing in Server due to some oversight.
>
Apparently Redhat does not like thi
On 3 June 2014 11:29, T.C. Hollingsworth wrote:
> You can file a bug with RHEL rel-eng here:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=releng&version=7.0
>
> Of course, supporting Workstation in general would be very nice, so
> your other t
I've asked the epel7 branch of libvncserver which is missing in ppc as per
packaging policy guidelines:
https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
I will be adding the same epel7 package with a prefixed 0 in the release
field.
SCM request:
https://bugzilla.redhat.com/sh
On 2 June 2014 16:46, T.C. Hollingsworth wrote:
> On Mon, Jun 2, 2014 at 1:59 AM, Simone Caronni
> wrote:
> > Hello,
> >
> > I was looking to build a package on epel7 that is relying on
> jansson-devel.
> >
> > The -devel subpackage is generated as nor
On 2 June 2014 11:09, Simone Caronni wrote:
> On 2 June 2014 11:04, Dan Horák wrote:
>
>> EPEL builds against the Server + Server-optional variant of RHEL -
>> http://koji.fedoraproject.org/koji/taginfo?tagID=258
>>
>
> Is this the final "setup" of EP
On 2 June 2014 11:04, Dan Horák wrote:
> EPEL builds against the Server + Server-optional variant of RHEL -
> http://koji.fedoraproject.org/koji/taginfo?tagID=258
>
Is this the final "setup" of EPEL for RHEL 7 that will be available for all
the time the distribution is supported by Redhat?
Than
Hello,
I was looking to build a package on epel7 that is relying on jansson-devel.
The -devel subpackage is generated as normally from the main jansson
package, but in case of epel7 the resulting rpm is included in the
Workstation-optional channel:
http://ftp.redhat.com/redhat/rhel/rc/7/Workstat
On 1 April 2014 13:55, Simone Caronni wrote:
> On 1 April 2014 12:58, Susi Lehtola wrote:
>
>> Uhm, so this is just about a virtual Provides?
>>
>> TeXLive *does* have latex. Just install texlive-latex.
>>
>
> Ok, I confirm is related to the texlive ver
On 1 April 2014 12:58, Susi Lehtola wrote:
> Uhm, so this is just about a virtual Provides?
>
> TeXLive *does* have latex. Just install texlive-latex.
>
Ok, I confirm is related to the texlive version in RHEL 7.
I reworked all the BuildRequires in the SPEC file with the "new" texlive
syntax (i.e
On 1 April 2014 11:42, Susi Lehtola wrote:
> > Ok, I found the issue. The texlive in EPEL 7 is too old and does not
> > contain the sub-packages I'm using.
> > I hope they will update it before release; texlive 2013 was released mid
> > 2013 and we're now in 2014.
>
> You can probably forget abou
On 1 April 2014 11:26, Parag N(पराग़) wrote:
> On Tue, Apr 1, 2014 at 2:07 PM, Simone Caronni
> wrote:
> > Hello,
> >
> > is there any plan to have texlive in EPEL 7?
>
> The texlive package already exists in RHEL7. See
> http://ftp.redhat.com/redhat/rhel/be
Hello,
is there any plan to have texlive in EPEL 7?
I need it but wouldn't dare asking for the branch myself... looks
complicated and I don't have any direct experience with it.
Thanks & regards,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore
On 20 March 2014 22:55, Dennis Gilmore wrote:
>
> On Tue, 18 Mar 2014 13:40:42 +0100
> Simone Caronni wrote:
> > as a contributor I would really like to have i686 as one of the main
> > architectures. With the current situation, there's no chance to
> > rebuild
Hello,
On 18 March 2014 11:54, Jim Perrin wrote:
> Specifically we intend to continue producing for the i686
> architecture, as well as adding ARMv7 builds. These additional builds
> will allow users with legacy hardware (or 32bit cloud images) to migrate
> to newer versions while addressing the
Hello,
maybe I missed this, but I would like to know what's the status of EPEL 7
32 bit (i686) support.
I see that in Koji all libraries are x86_64 or ppc64. Shouldn't we have
i686 libraries as well, much like in Fedora?
Also considering that the system itself has many 32 bit libraries:
https://
Hello,
I would like to update the current NDOUtils 1.4b9 (2009-10-27) to the
latest 1.5.2 (2012-06-08) in both epel 5 and 6.
The former maintainer was not using the package, no one volunteered for it
so it was retired in Fedora in 2012. As it could not be retired from
released branches, this is t
Hello,
out of the list of packages for which I have requested epel7 branches,
there's libssh that doesn't seem to work.
The branch has been created in git (I can checkout, add, etc.) but Koji
refuses me to build the package with the following error:
BuildError: package libssh not in list for tag
36 matches
Mail list logo
