[EPEL-devel] Re: postgis-2.0.7-2.el7 still in epel7-testing

2019-04-21 Thread Sérgio Basto
On Fri, 2019-04-12 at 09:36 +0200, Danny Smit wrote:
> Hi all,
> 
> I'm looking for a fix in postgis, which seems to be fixed already in
> postgis-2.0.7-2.el7.
> 
> However that package seems to be 'stuck' in the epel7-testing
> repository for a long time:
>   https://koji.fedoraproject.org/koji/buildinfo?buildID=750618
>   https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b6c229157e
> 
> Can the package be pushed to stable?

I gave +1 karma and more one and package will be pushed to updates
automatically .

Can someone give one more positive karma ? please 

Thanks

> -- 
> Kind regards,
> Danny
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to 
> epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: cairo issue with RHEL 7.6?

2018-10-30 Thread Sérgio Basto
On Tue, 2018-10-30 at 20:57 -0600, Orion Poplawski wrote:
> I'm getting this:
> 
> DEBUG util.py:439:  Error: Package: cairo-1.15.12-3.el7.ppc64 (build)
> DEBUG util.py:439: Requires: libEGL.so.1()(64bit)
> DEBUG util.py:439:  Error: Package: cairo-1.15.12-3.el7.ppc64 (build)
> DEBUG util.py:439: Requires: libGL.so.1()(64bit)
> 
> https://apps.fedoraproject.org/koschei/package/logback?collection=epe
> l7
> 
> That appears to be the appropriate latest version of cairo in RHEL
> 7.6. 
> Did it somehow not get properly rebuilt against the latest mesa-
> libGL/EGL?

+1 

perl-Qt's dependencies failed to resolve in EPEL 7
https://apps.fedoraproject.org/koschei/package/perl-Qt?collecti
on=epel7

debconf's dependencies failed to resolve in EPEL 7
https://apps.fedoraproject.org/koschei/package/debconf?collecti
on=epel7

smokeqt's dependencies failed to resolve in EPEL 7
https://apps.fedoraproject.org/koschei/package/smokeqt?collecti
on=epel7

clamav's dependencies failed to resolve in EPEL 7
https://apps.fedoraproject.org/koschei/package/clamav?collectio
n=epel7

mlt's dependencies failed to resolve in EPEL 7
https://apps.fedoraproject.org/koschei/package/mlt?collection=e
pel7


> 
> -- 
> Orion Poplawski
> Manager of NWRA Technical Systems  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.
> org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/epel-dev
> e...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] [Fwd: [includepkgs=devtoolset*] Re: Cannot find -latomic when building for epel7 aarch64]

2018-10-22 Thread Sérgio Basto
Hello, 

Moving this subject to epel-devel ML 

Generically where I find devtoolset howto(s) ? and what should be mock-
core-configs ? 

And I'm confused what difference of rh-eclipse46 and devtoolset-4 [1] ?

Thanks 
[1]
https://www.softwarecollections.org/en/scls/rhscl/rh-eclipse46/
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/



 Forwarded Message 
From: Sérgio Basto 
Reply-to: Development discussions related to Fedora

To: Development discussions related to Fedora 
Subject: [includepkgs=devtoolset*] Re: Cannot find -latomic when
building for epel7 aarch64
Date: Mon, 22 Oct 2018 16:48:45 +0100

On Sat, 2018-10-20 at 13:03 -0400, Todd Zullinger wrote:
> Sérgio Basto wrote:
> > I had checked mock-core-config [1] , which are in use in copr (I
> > guess)
> > and can't enable developer tools .
> > But on koji runs well , can you review this ? please .
> > 
> > I could build azureus [4] on koji [2] which need eclipse-swt , but
> > not
> > on copr `Error: No Package found for rh-eclipse46-eclipse-swt >=
> > 3.5` 
> > Unfortunately I didn't have much time to dig it ... 
> 
> Packages from the SCL repos in mock-core-configs are
> restricted via the following config entry¹:
> 
> includepkgs=devtoolset*
> 
> That limit was not included in the initial koji
> configuration, but my understanding was that was going to be
> corrected.
> 
> The only packages allowed to be used (or more specifically,
> BuildRequired) from the SCL repos in EPEL are devtoolset*.
> (Feel free to follow up on epel-devel on that, as that's
> where the folks who know best are.)
> 
> ¹ https://github.com/rpm-software-management/mock/blob/devel/mock-cor
> e-configs/etc/mock/epel-7-x86_64.cfg#L62


Thank you for the reply 

I improve my spec [1], I'm using devtoolset-4, I could build and run
azureus on el7 but unfortunately, this collection is EOL since Dec
2017; so I don't know if it is a good test, anyway with actual mock-
core-configs we can't install dependencies (rh-java-common-jpackage-
utils and rh-java-common-runtime).
if I add to [sclo-rh] includepkgs=devtoolset*,rh* it works .

In resume [2] fails with: [3]

Thanks 

[1]
https://github.com/sergiomb2/azureus/commits/master

[2]
mock -r epel-7-x86_64 --install devtoolset-4-eclipse-swt

[3]
Problem: cannot install the best candidate for the job
  - nothing provides rh-java-common-runtime needed by devtoolset-4-
eclipse-swt-1:4.5.2-5.4.el7.x86_64


-- 
Sérgio M. B.
___
devel mailing list -- de...@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@list
s.fedoraproject.org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: debootstrap, dpkg and man-pages-it

2018-05-22 Thread Sérgio Basto
On Tue, 2018-05-22 at 04:10 +0100, Sérgio Basto wrote:
> Hello,
> 
> On Sat, 2018-04-28 at 07:02 +0100, Andrew C Aitchison wrote:
> > From Fedora EPEL 6 updates-testing report Tuesday, 24 April 2018:
> > 
> > > The following Fedora EPEL 6 Security updates need testing:
> > 
> > ...
> > > The following builds have been pushed to Fedora EPEL 6 updates-
> > > testing
> > > debmirror-2.29-1.el6
> > > debootstrap-1.0.97-1.el6
> > > ocserv-0.12.0-1.el6 php-symfony-psr-http-message-bridge-1.0.2-
> > > 2.el6
> > > php-webmozart-assert-1.3.0-1.el6
> > 
> > When I attempt to update debootstrap with
> > 
> > # yum update
> > /var/cache/yum/x86_64/6.9/epel-testing/packages/debootstrap-1.0.97-
> > 1.el6.noarch.rpm
> > 
> > I get (sumary here, full log below the line):
> > Downloading Packages:
> > Running rpm_check_debug
> > Running Transaction Test
> > 
> > Transaction Check Error:
> >file /usr/share/man/it/man5/dpkg.cfg.5.gz from install of
> > dpkg-1.16.18-2.el6x86_64 conflicts with file from package
> > man-pages-it-2.80-6.el6.noarch
> > 
> > 
> > (Parenthetically, given rpmquiery -i debootstrap
> >Description :
> >debootstrap is used to create a Debian base system from scratch,
> >without requiring the availability of dpkg or apt...
> > It seems odd that we now require dpkg. If I get to choose, could
> > you
> > remove the dependency rather than update the decription :-) ?)
> 
> hum !?!
> 
> https://src.fedoraproject.org/rpms/debootstrap/c/6f76bb966ef3b1067db8
> 6d2dae748f50a0cdc117?branch=master
> 
> but the main problem is in man-pages-it-2.80-6.el6.noarch which
> provide a man page for dpkg 

I have submitted a fix [1]

[1]
https://bodhi.fedoraproject.org/updates/debootstrap-1.0.100-1.el6

Thanks, 
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/35G25PHJXVHEDM4PTQ5RXTPCDDVRUZ2E/


[EPEL-devel] Re: php

2018-05-22 Thread Sérgio Basto
On Tue, 2018-05-22 at 11:05 -0400, Stephen John Smoogen wrote:
> On 21 May 2018 at 23:18, Sérgio Basto <ser...@serjux.com> wrote:
> > Hi,
> > Latest php 5.4 release was in 2015-Sep-04 ( php-5.4.45.tar.gz )
> > 3 years ago ...
> > We will have el 7 until 2024 , more 6 years, can we update php to
> > 5.6
> > on el 7 ? or PHP apps for epel have to move to remi repo ?
> 
> I am expecting they will need to move to the remi repo because php-
> 5.4
> is shipped in RHEL and we do not over-write those packages. In the
> past RHEL would have shipped a php56 which would have done this, but
> I
> expect that they instead are wanting people to use SCL's for this.
> Which would require us to either ship the SCLs ourselves (as we can't
> assume a person has that repo turned on) or we create a repository
> which requires them so that people aren't broken.

I have to check SCL , but SCL-epel sounds good to me 

> There is another option where someone packages up the php56 rpms in
> some way which could be shipped in EPEL, but I think that is a large
> amount of work and I believe remi has pointed people to use scl's
> instead.

-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/FH2MIFSMFG7UJFN6ZBBDSZGFZSERGTRZ/


[EPEL-devel] php

2018-05-21 Thread Sérgio Basto
Hi,
Latest php 5.4 release was in 2015-Sep-04 ( php-5.4.45.tar.gz ) 
3 years ago ... 
We will have el 7 until 2024 , more 6 years, can we update php to 5.6
on el 7 ? or PHP apps for epel have to move to remi repo ? 

Thanks, 
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/Q36GKOUJV2FT6WECHIVSFTCJZ5A4WIXU/


[EPEL-devel] Re: debootstrap, dpkg and man-pages-it

2018-05-21 Thread Sérgio Basto
Hello,

On Sat, 2018-04-28 at 07:02 +0100, Andrew C Aitchison wrote:
> From Fedora EPEL 6 updates-testing report Tuesday, 24 April 2018:
> 
> > The following Fedora EPEL 6 Security updates need testing:
> 
> ...
> > The following builds have been pushed to Fedora EPEL 6 updates-
> > testing
> > debmirror-2.29-1.el6
> > debootstrap-1.0.97-1.el6
> > ocserv-0.12.0-1.el6 php-symfony-psr-http-message-bridge-1.0.2-2.el6
> > php-webmozart-assert-1.3.0-1.el6
> 
> When I attempt to update debootstrap with
> 
> # yum update
> /var/cache/yum/x86_64/6.9/epel-testing/packages/debootstrap-1.0.97-
> 1.el6.noarch.rpm
> 
> I get (sumary here, full log below the line):
> Downloading Packages:
> Running rpm_check_debug
> Running Transaction Test
> 
> Transaction Check Error:
>file /usr/share/man/it/man5/dpkg.cfg.5.gz from install of
> dpkg-1.16.18-2.el6x86_64 conflicts with file from package
> man-pages-it-2.80-6.el6.noarch
> 
> 
> (Parenthetically, given rpmquiery -i debootstrap
>Description :
>debootstrap is used to create a Debian base system from scratch,
>without requiring the availability of dpkg or apt...
> It seems odd that we now require dpkg. If I get to choose, could you
> remove the dependency rather than update the decription :-) ?)

hum !?!

https://src.fedoraproject.org/rpms/debootstrap/c/6f76bb966ef3b1067db86d
2dae748f50a0cdc117?branch=master

but the main problem is in man-pages-it-2.80-6.el6.noarch which provide
a man page for dpkg 



-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/PMLJLKBCD3JPM5AAGI4IPMLADE4AVVTM/


[EPEL-devel] Re: [fedora-java] Re: Re: mod_jk

2018-04-29 Thread Sérgio Basto
On Sat, 2018-04-28 at 08:45 +, Bill Chatfield wrote:
> mod_jk is easy to build from source. I just did it
> myself. The instructions are easy to understand, there are only a few
> steps, and it actually compiles without errors. You're not going to
> waste most of a day getting it to build. It takes about 15 minutes at
> the most. It has some significant advantages over mod_proxy in that
> it has better load balancing and fail-over.

But now we have mod_proxy_ajp, with support to load balancing and ajp
things, I'm using it now and it is even more easy to configure . And I
don't need to build any package .
> 
> 
> 
> 
> 
> On Sunday, April 22, 2018, 3:51:00 PM EDT,
> Sérgio Basto <ser...@serjux.com> wrote:
> 
> 
> 
> 
> 
> On Sun, 2018-04-22 at 09:46 -0500, Rex Dieter
> wrote:
> > Sérgio Basto wrote:
> > 
> > > To simplify my concerns, what is easy way to install mod_jk ? on
> > > epel 7and
> > > 6 BTW
> > 
> > I went through similar searching for my @dayjob awhile back, ended
> > up 
> > switching to use apache's mod_proxy
> 
> ah mod_proxy_ajp.so is available on httpd package of el6, el7 and 
> Fedora 
> 
> Thanks for the tips 
> 
> -- 
> Sérgio M. B.
> ___
> java-devel mailing list -- java-de...@lists.fedoraproject.org
> To unsubscribe send an email to java-devel-leave@lists.fedoraproject.
> org
> 
> 
> 
> ___
> java-devel mailing list -- java-de...@lists.fedoraproject.org
> To unsubscribe send an email to java-devel-leave@lists.fedoraproject.
> org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: mod_jk

2018-04-22 Thread Sérgio Basto
On Sun, 2018-04-22 at 09:46 -0500, Rex Dieter wrote:
> Sérgio Basto wrote:
> 
> > To simplify my concerns, what is easy way to install mod_jk ? on
> > epel 7and
> > 6 BTW
> 
> I went through similar searching for my @dayjob awhile back, ended
> up 
> switching to use apache's mod_proxy

ah mod_proxy_ajp.so is available on httpd package of el6, el7 and 
Fedora 

Thanks for the tips 

-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: mod_jk rpm

2018-04-22 Thread Sérgio Basto
On Sun, 2018-04-22 at 11:55 +0200, Reindl Harald wrote:
> Am 22.04.2018 um 02:52 schrieb Sérgio Basto:
> > I needed mod_jk for some tomcat applications and it was one
> > adventure 
> > because last build of mod_jk is about 2015 and jpp project died in
> > 2009
> 
> https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html

OK I see that we also have mod_proxy_ajp [1] .
But what I meant , we don't have any of these in yum/dnf repos, neither
we have any src.rpm updated since 2015, or am I missing something ? 

Thanks 

[1]
https://wiki.apache.org/tomcat/FAQ/Connectors#Q2
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: mod_jk rpm

2018-04-22 Thread Sérgio Basto
On Sun, 2018-04-22 at 11:55 +0200, Reindl Harald wrote:
> Am 22.04.2018 um 02:52 schrieb Sérgio Basto:
> > I needed mod_jk for some tomcat applications and it was one
> > adventure 
> > because last build of mod_jk is about 2015 and jpp project died in
> > 2009
> 
> https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: mod_jk

2018-04-21 Thread Sérgio Basto
Sorry just some more notes:
http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/JBCS/SRPMS
/
for example these jbcs-httpd24 , doesn't make sense because el6 haveapache 2.2 

https://access.redhat.com/solutions/3357951

On Sun, 2018-04-22 at 02:23 +0100, Sérgio Basto wrote:
> meanwhile upstream updated to 1.2.43 [1] when last version found in
> rpms is 1.2.41
> 
> 
> [1]
> https://github.com/apache/tomcat-connectors/releases/tag/JK_1_2_43
> 
> 
> On Sun, 2018-04-22 at 01:52 +0100, Sérgio Basto wrote:
> > Hello, 
> > 
> > First my notes: 
> > https://issues.jboss.org/browse/JBCS-119?_sscc=t
> > http://ftp.riken.jp/Linux/redhat/ftp.redhat.com/linux/enterprise/6S
> > er
> > ver/en/JBEAP/SRPMS/
> > https://bugzilla.redhat.com/show_bug.cgi?id=1366581
> > https://developers.redhat.com/products/eap/download/
> > https://bugzilla.redhat.com/show_bug.cgi?id=1369758
> > 
> > 
> > I needed mod_jk for some tomcat applications and it was one
> > adventure 
> > because last build of mod_jk is about 2015 and jpp project died in
> > 2009
> > 
> > To simplify my concerns, what is easy way to install mod_jk ? on
> > epel
> > 7and 6 BTW 
> > 
> > we have JBCS (jboss something ) and we have JBEAP ? what is the
> > difference ? 
> > 
> > Thanks,
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: mod_jk

2018-04-21 Thread Sérgio Basto
meanwhile upstream updated to 1.2.43 [1] when last version found in
rpms is 1.2.41


[1]
https://github.com/apache/tomcat-connectors/releases/tag/JK_1_2_43


On Sun, 2018-04-22 at 01:52 +0100, Sérgio Basto wrote:
> Hello, 
> 
> First my notes: 
> https://issues.jboss.org/browse/JBCS-119?_sscc=t
> http://ftp.riken.jp/Linux/redhat/ftp.redhat.com/linux/enterprise/6Ser
> ver/en/JBEAP/SRPMS/
> https://bugzilla.redhat.com/show_bug.cgi?id=1366581
> https://developers.redhat.com/products/eap/download/
> https://bugzilla.redhat.com/show_bug.cgi?id=1369758
> 
> 
> I needed mod_jk for some tomcat applications and it was one
> adventure 
> because last build of mod_jk is about 2015 and jpp project died in
> 2009
> 
> To simplify my concerns, what is easy way to install mod_jk ? on epel
> 7and 6 BTW 
> 
> we have JBCS (jboss something ) and we have JBEAP ? what is the
> difference ? 
> 
> Thanks,
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] mod_jk

2018-04-21 Thread Sérgio Basto
Hello, 

First my notes: 
https://issues.jboss.org/browse/JBCS-119?_sscc=t
http://ftp.riken.jp/Linux/redhat/ftp.redhat.com/linux/enterprise/6Server/en/JBEAP/SRPMS/
https://bugzilla.redhat.com/show_bug.cgi?id=1366581
https://developers.redhat.com/products/eap/download/
https://bugzilla.redhat.com/show_bug.cgi?id=1369758


I needed mod_jk for some tomcat applications and it was one adventure 
because last build of mod_jk is about 2015 and jpp project died in 2009

To simplify my concerns, what is easy way to install mod_jk ? on epel 7and 6 
BTW 

we have JBCS (jboss something ) and we have JBEAP ? what is the
difference ? 

Thanks,
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: request commit access to python-qt5 dist-git repo to add epe7 branch

2018-03-28 Thread Sérgio Basto
On Tue, 2018-03-27 at 13:46 -0500, Rex Dieter wrote:
> Sérgio Basto wrote:
> 
> > On Tue, 2018-03-27 at 11:53 -0500, Rex Dieter wrote:
> > > Sérgio Basto wrote:
> > > 
> > > > On Mon, 2018-03-26 at 15:33 -0500, Rex Dieter wrote:
> > > > > Sérgio Basto wrote:
> > > > > 
> > > > > > On Tue, 2018-03-06 at 16:15 -0600, Rex Dieter wrote:
> > > > > > > I'd be ok with an epel7-only python3-sip
> > > > > > > 
> > > > > > > Since it is a new package (not a branch of an existing
> > > > > > > one),
> > > > > > > then
> > > > > > > it
> > > > > > > would require a new package review.
> > > > > > > 
> > > > > > > It would be a bit of shame though, having to fork things
> > > > > > > like
> > > > > > > that.
> > > > > > 
> > > > > > I tried this solution (epel7-only python3-sip) but
> > > > > > BUILDSTDERR: Error: This version of PyQt5 requires sip
> > > > > > 4.19.4
> > > > > > or
> > > > > > later.
> > > > > > when el7 have  sip-devel  x86_64 4.14.6-
> > > > > > 4.el7 base
> > > > > > 
> > > > > > if we do package sip-qt5 we must override
> > > > > > /usr/lib64/python2.7/site-
> > > > > > packages/sip.so
> > > > > > it is possible sip-qt5 provides and obsolete sip (4.14.6-
> > > > > > 4.el7)
> > > > > > ?
> > > > > 
> > > > > Not possible (by policy).  It should be able to work without
> > > > > doing
> > > > > that, but
> > > > > it may require patching.
> > > > 
> > > > I don't see how. In python2, how "import sip" will work ?
> > > > "import
> > > > sip-qt5
> > > > as sip" ?
> > > 
> > > I thought the context here was your desire to add *only python3*
> > > sip/python-
> > > qt5 to epel ?
> > 
> > That was if pyhton2-sip was enough , but sip 4.14.6 is not enough
> > for
> > python2-qt5-devel ...
> > 
> > But thinking, we might only build python3-qt5 ?  ok,  let me review
> > this again , seems enough for my openshot and subdownloader 
> 
> Yes, that's really the only viable option here, to do *only* python3-
> sip and 
> python3-qt5

Done, sip : 
https://src.fedoraproject.org/fork/sergiomb/rpms/sip/c/84b5266e6d36d6e20c23bafe4da429fa0b98e0de?branch=master

and python3-qt5:
https://src.fedoraproject.org/fork/sergiomb/rpms/python-qt5/commits/master


As a note python34-sip-devel and sip-devel (pyhton2 version) can't be installed 
at same time [1]
but it is correct, we can only have one macros.sip in the system , is it a 
problem ? 
So can we do branches of sip and python-qt5 for epel-7 using the same packages 
but just build python3 part ? 

Thanks,

[1]
Problem: problem with installed package sip-devel-4.14.6-4.el7.x86_64

  - package sip-devel-4.14.6-4.el7.x86_64 requires sip-macros = 4.14.6-4.el7, 
but none of the providers can be installed
  - package python34-sip-macros-4.19.8-4.el7.centos.noarch obsoletes sip-macros 
< 4.15.5 provided by sip-macros-4.14.6-4.el7.x
86_64
  - package python34-sip-devel-4.19.8-4.el7.centos.x86_64 requires 
python34-sip-macros = 4.19.8-4.el7.centos, but none of the 
providers can be installed


rpm -q sip-macros -l
/etc/rpm/macros.sip

cat /etc/rpm/macros.sip
%_sip_api_major 9
%_sip_api_minor 2
%_sip_api %{_sip_api_major}.%{_sip_api_minor}


rpm -q python34-sip-macros -l
/usr/lib/rpm/macros.d/macros.sip

cat /usr/lib/rpm/macros.d/macros.sip
%_sip_api_major 12
%_sip_api_minor 4
%_sip_api %{_sip_api_major}.%{_sip_api_minor}

-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: request commit access to python-qt5 dist-git repo to add epe7 branch

2018-03-27 Thread Sérgio Basto
On Tue, 2018-03-27 at 11:53 -0500, Rex Dieter wrote:
> Sérgio Basto wrote:
> 
> > On Mon, 2018-03-26 at 15:33 -0500, Rex Dieter wrote:
> > > Sérgio Basto wrote:
> > > 
> > > > On Tue, 2018-03-06 at 16:15 -0600, Rex Dieter wrote:
> > > > > I'd be ok with an epel7-only python3-sip
> > > > > 
> > > > > Since it is a new package (not a branch of an existing one),
> > > > > then
> > > > > it
> > > > > would require a new package review.
> > > > > 
> > > > > It would be a bit of shame though, having to fork things like
> > > > > that.
> > > > 
> > > > I tried this solution (epel7-only python3-sip) but
> > > > BUILDSTDERR: Error: This version of PyQt5 requires sip 4.19.4
> > > > or
> > > > later.
> > > > when el7 have  sip-devel  x86_64 4.14.6-4.el7 base
> > > > 
> > > > if we do package sip-qt5 we must override
> > > > /usr/lib64/python2.7/site-
> > > > packages/sip.so
> > > > it is possible sip-qt5 provides and obsolete sip (4.14.6-4.el7) 
> > > > ?
> > > 
> > > Not possible (by policy).  It should be able to work without
> > > doing
> > > that, but
> > > it may require patching.
> > 
> > I don't see how. In python2, how "import sip" will work ? "import
> > sip-qt5
> > as sip" ?
> 
> I thought the context here was your desire to add *only python3*
> sip/python-
> qt5 to epel ?

That was if pyhton2-sip was enough , but sip 4.14.6 is not enough for
python2-qt5-devel ... 

But thinking, we might only build python3-qt5 ?  ok,  let me review
this again , seems enough for my openshot and subdownloader  
 
Thanks,
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: request commit access to python-qt5 dist-git repo to add epe7 branch

2018-03-26 Thread Sérgio Basto
On Mon, 2018-03-26 at 15:33 -0500, Rex Dieter wrote:
> Sérgio Basto wrote:
> 
> > On Tue, 2018-03-06 at 16:15 -0600, Rex Dieter wrote:
> > > I'd be ok with an epel7-only python3-sip
> > > 
> > > Since it is a new package (not a branch of an existing one), then
> > > it
> > > would require a new package review.
> > > 
> > > It would be a bit of shame though, having to fork things like
> > > that.
> > 
> > I tried this solution (epel7-only python3-sip) but
> > BUILDSTDERR: Error: This version of PyQt5 requires sip 4.19.4 or
> > later.
> > when el7 have  sip-devel  x86_64 4.14.6-4.el7 base
> > 
> > if we do package sip-qt5 we must override
> > /usr/lib64/python2.7/site-
> > packages/sip.so
> > it is possible sip-qt5 provides and obsolete sip (4.14.6-4.el7) ?
> 
> Not possible (by policy).  It should be able to work without doing
> that, but 
> it may require patching.

I don't see how. In python2, how "import sip" will work ? "import sip-qt5 as 
sip" ? 

Best regards
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: request commit access to python-qt5 dist-git repo to add epe7 branch

2018-03-26 Thread Sérgio Basto
On Tue, 2018-03-06 at 16:15 -0600, Rex Dieter wrote:
> I'd be ok with an epel7-only python3-sip
> 
> Since it is a new package (not a branch of an existing one), then it
> would require a new package review.
> 
> It would be a bit of shame though, having to fork things like that.

I tried this solution (epel7-only python3-sip) but 
BUILDSTDERR: Error: This version of PyQt5 requires sip 4.19.4 or later.
when el7 have  sip-devel  x86_64 4.14.6-4.el7 base

if we do package sip-qt5 we must override /usr/lib64/python2.7/site-
packages/sip.so

it is possible sip-qt5 provides and obsolete sip (4.14.6-4.el7) ? 

As a side note for epel-devel we also need python3-sip which is not
provide by el7, since only epel-7 have python3, isn't it ?

 

> On Tue, Mar 6, 2018 at 2:02 PM, Sérgio Basto <ser...@serjux.com>
> wrote:
> > new suggestion for new sip: sip-qt5
> > 
> > On Mon, 2018-03-05 at 16:35 +, Sérgio Basto wrote:
> > > I study this a little , the sip on rhel is sip 4.14 and we need
> > > sip 4.15+ , but should be cool have python3-qt5, even we they
> > > update sip in RHEL won't have pyhton3 bindings since python34 is
> > > in epel .
> > > So can we consider do a package named sip5 (for qt5) just in
> > > epel7 ?
> > > 
> > > On Mon, 2018-03-05 at 10:20 -0600, Rex Dieter wrote:
> > > > Since the requisite version of sip cannot go into epel7, I'm
> > > > not sure if it makes sense to make an epel7 branch for python-
> > > > qt5.  I'm guessing no.
> > > > 
> > > > On Sat, Mar 3, 2018 at 6:37 PM, Sérgio Basto <ser...@serjux.com
> > > > > wrote:
> > > > > Hello,
> > > > > Same email to python-qt5
> > > > > 
> > > > > From [1] I'd like ask, please, request to commit or please
> > > > > branch
> > > > > python-qt5 into epel7 (after build sip ) and build the
> > > > > package from
> > > > > master  .
> > > > > I'd like bring python-qt5 to epel7 , as explain in PR #3 [2]
> > > > > epel 6 for now is not in the plans .
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > [2]
> > > > > https://src.fedoraproject.org/rpms/sip/pull-request/3
> > > > > 
> > > > > I'd like have python-qt5 on epel7 to build openshot and
> > > > > probably other
> > > > > packages , for that I need sip
> > > > > 
> > > > > I tested in copr [1] and build openshot successfully  for
> > > > > epel6 we
> > > > > need phonon-qt5 and phonon-qt5-backend-gstreamer , but epel6
> > > > > doesn't
> > > > > have gstreame1 for backend package ...
> > > > > 
> > > > > 
> > > > > [1]
> > > > > https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToP
> > > > > kgdb#How_do_I_request_commit_access_to_a_dist-git_repo.3F
> > > > > 
> > > > > How do I request commit access to a dist-git repo?
> > > > > 
> > > > > Email the packagename-ow...@fedoraproject.org alias asking to
> > > > > be given
> > > > > access, or file a bugzilla bug on the package asking for
> > > > > access.
> > > > > 
> > > > > 
> > > > > --
> > > > > Sérgio M. B.
> > > 
> > > -- 
> > > Sérgio M. B.
> > 
> > -- 
> > Sérgio M. B.
> 
> 
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Looking for testers: Clamav 0.99.4 EL-6

2018-03-12 Thread Sérgio Basto
On Mon, 2018-03-12 at 17:30 -0400, Stephen John Smoogen wrote:
> There is a security update waiting in epel-testing for 0.99.4.
> 
> I have tested it in my setup and it looks to be working but it needs
> more testing
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7e91105260

BTW we also need karma for EL-7 please 

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aacf1b47d6

Thanks, 

> -- 
> Stephen J Smoogen.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.
> org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: qt5 dependency problem

2018-03-04 Thread Sérgio Basto
On Sat, 2018-03-03 at 13:20 -0500, Christopher Brown wrote:
> On 02/24/2018 02:15 PM, Sérgio Basto wrote:
> > On Sat, 2018-02-24 at 17:45 +, Christopher Brown wrote:
> > > Hi,
> > > 
> > > In trying to install trojita, I got the following error:
> > > 
> > > $ sudo yum install trojita
> > > Loaded plugins: langpacks
> > > Resolving Dependencies
> > > --> Running transaction check
> > > ---> Package trojita.x86_64 0:0.7-4.el7 will be installed
> > > --> Processing Dependency: libQt5WebKitWidgets.so.5(Qt_5)(64bit)
> > > for
> > > package: trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libKF5Gpgmepp-pthread.so.5()(64bit)
> > > for
> > > package: trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libKF5QGpgme.so.5()(64bit) for
> > > package:
> > > trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libQt5WebKit.so.5()(64bit) for
> > > package:
> > > trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libQt5WebKitWidgets.so.5()(64bit) for
> > > package: trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libmimetic.so.0()(64bit) for package:
> > > trojita-0.7-4.el7.x86_64
> > > --> Processing Dependency: libqt5keychain.so.1()(64bit) for
> > > package:
> > > trojita-0.7-4.el7.x86_64
> > > --> Running transaction check
> > > ---> Package kf5-gpgmepp.x86_64 0:16.04.3-1.el7 will be installed
> > > ---> Package mimetic.x86_64 0:0.9.8-6.el7 will be installed
> > > ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed
> > > --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for
> > > package:
> > > qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5Positioning.so.5(Qt_5)(64bit)
> > > for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5Sensors.so.5(Qt_5)(64bit) for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5WebChannel.so.5(Qt_5)(64bit) for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5Positioning.so.5()(64bit) for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5Sensors.so.5()(64bit) for
> > > package:
> > > qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: libQt5WebChannel.so.5()(64bit) for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > ---> Package qtkeychain-qt5.x86_64 0:0.7.0-1.el7 will be
> > > installed
> > > --> Processing Dependency: qtkeychain(x86-64) = 0.7.0-1.el7 for
> > > package: qtkeychain-qt5-0.7.0-1.el7.x86_64
> > > --> Running transaction check
> > > ---> Package qt5-qtlocation.x86_64 0:5.6.1-10.el7 will be
> > > installed
> > > ---> Package qt5-qtsensors.x86_64 0:5.6.1-10.el7 will be
> > > installed
> > > ---> Package qt5-qtwebchannel.x86_64 0:5.6.1-10.el7 will be
> > > installed
> > > ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed
> > > --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for
> > > package:
> > > qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for
> > > package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> > > ---> Package qtkeychain.x86_64 0:0.7.0-1.el7 will be installed
> > > --> Finished Dependency Resolution
> > > Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel)
> > > Requires: qt5-qtbase(x86-64) = 5.6.2
> > > Installed: qt5-qtbase-5.6.1-10.el7.x86_64 (@sl)
> > > qt5-qtbase(x86-64) = 5.6.1-10.el7
> > > Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel)
> > > Requires: qt5-qtdeclarative(x86-64) = 5.6.2
> > > Installed: qt5-qtdeclarative-5.6.1-10.el7.x86_64
> > > (@sl)
> > > qt5-qtdeclarative(x86-64) = 5.6.1-10.el7
> > >   You could try using --skip-broken to work around the problem
> > >   You could try running: rpm -Va --nofiles --nodigest
> > > $
> > > 
> > > ...Any suggestions?
> > 
> > mock -r epel-7-x86_64-rpmfusion_free --install trojita
> > 
> > works fine here, it  installs  qt5-qtdeclarative-5.6.2-1.el7  and
> >   qt5-qtbase-5.6.2-1.el7 from base repo
> > 
> > 
> > 
> 
> Thanks for the reply. But I already use epel and nux, and when I
> install 
> rpmfusion, I get many dependency errors reported for other packages.
> Is 
> there another yum way (I mean, aside from downloading the individual 
> packages and localinstall'ing them)?

yum distro-sync --disable-repo=nux

> Chris
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: qt5 dependency problem

2018-02-24 Thread Sérgio Basto
On Sat, 2018-02-24 at 17:45 +, Christopher Brown wrote:
> Hi,
> 
> In trying to install trojita, I got the following error:
> 
> $ sudo yum install trojita
> Loaded plugins: langpacks
> Resolving Dependencies
> --> Running transaction check
> ---> Package trojita.x86_64 0:0.7-4.el7 will be installed
> --> Processing Dependency: libQt5WebKitWidgets.so.5(Qt_5)(64bit) for
> package: trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libKF5Gpgmepp-pthread.so.5()(64bit) for
> package: trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libKF5QGpgme.so.5()(64bit) for package:
> trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libQt5WebKit.so.5()(64bit) for package:
> trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libQt5WebKitWidgets.so.5()(64bit) for
> package: trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libmimetic.so.0()(64bit) for package:
> trojita-0.7-4.el7.x86_64
> --> Processing Dependency: libqt5keychain.so.1()(64bit) for package:
> trojita-0.7-4.el7.x86_64
> --> Running transaction check
> ---> Package kf5-gpgmepp.x86_64 0:16.04.3-1.el7 will be installed
> ---> Package mimetic.x86_64 0:0.9.8-6.el7 will be installed
> ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed
> --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for package:
> qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5Positioning.so.5(Qt_5)(64bit) for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5Sensors.so.5(Qt_5)(64bit) for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5WebChannel.so.5(Qt_5)(64bit) for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5Positioning.so.5()(64bit) for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5Sensors.so.5()(64bit) for package:
> qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: libQt5WebChannel.so.5()(64bit) for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> ---> Package qtkeychain-qt5.x86_64 0:0.7.0-1.el7 will be installed
> --> Processing Dependency: qtkeychain(x86-64) = 0.7.0-1.el7 for
> package: qtkeychain-qt5-0.7.0-1.el7.x86_64
> --> Running transaction check
> ---> Package qt5-qtlocation.x86_64 0:5.6.1-10.el7 will be installed
> ---> Package qt5-qtsensors.x86_64 0:5.6.1-10.el7 will be installed
> ---> Package qt5-qtwebchannel.x86_64 0:5.6.1-10.el7 will be installed
> ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed
> --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for package:
> qt5-qtwebkit-5.6.2-1.el7.x86_64
> --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for
> package: qt5-qtwebkit-5.6.2-1.el7.x86_64
> ---> Package qtkeychain.x86_64 0:0.7.0-1.el7 will be installed
> --> Finished Dependency Resolution
> Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel)
>Requires: qt5-qtbase(x86-64) = 5.6.2
>Installed: qt5-qtbase-5.6.1-10.el7.x86_64 (@sl)
>qt5-qtbase(x86-64) = 5.6.1-10.el7
> Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel)
>Requires: qt5-qtdeclarative(x86-64) = 5.6.2
>Installed: qt5-qtdeclarative-5.6.1-10.el7.x86_64 (@sl)
>qt5-qtdeclarative(x86-64) = 5.6.1-10.el7
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> $ 
> 
> ...Any suggestions?


mock -r epel-7-x86_64-rpmfusion_free --install trojita 

works fine here, it  installs  qt5-qtdeclarative-5.6.2-1.el7  and 
 qt5-qtbase-5.6.2-1.el7 from base repo 



> Thanks,
> Chris
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.
> org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Need to have some packages rebuilt in EPEL

2017-04-19 Thread Sérgio Basto
On Qua, 2017-04-19 at 15:16 -0600, Kevin Fenzi wrote:
> > 
> > ah , I built po4a to build dpkg on epel7 , but in fact po4a was
> > added
> > to centos 7 some moments before (I don't know if in RHEL7) 
> 
> It is. It's in rhel7-server-optional. Note that CentOS doesn't do any
> of
> the channel stuff, all of base, optional, etc all just are in their
> base
> repo IIRC.
> 
> 
> and that is
> > 
> > why it misses ppc64 arch [1] IIRC. BTW it also misses on ppc64,
> > perl-
> > gettext [2], maybe should be good also coordinate the fix of this
> > package too. 
> 
> Yeah, I started looking at the spec and saw that comment as well.
> 
> > 
> > If you could fix these 2 packages may the best is remove po4a from 
> > epel7 repo , if it is possible ... or bump epoch on RHEL7 ... 
> 
> Well, We can push out a lower version of the package, but people who
> already have the newer one installed will just still have that. It
> would
> fix new installs and the like though.
> 
> We definitely don't want to add an Epoch, because the idea is that we
> keep the EPEL package "older" than the RHEL one so people who install
> get the official one (if available on their arch).


I wrote my second reply before read this message anyway 
feel free to do anything with po4a.

Thanks,
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Need to have some packages rebuilt in EPEL

2017-04-19 Thread Sérgio Basto
On Qua, 2017-04-19 at 21:51 +0100, Sérgio Basto wrote:
> On Qua, 2017-04-19 at 12:03 -0600, Kevin Fenzi wrote:
> > 
> > On 04/14/2017 12:05 PM, Stephen John Smoogen wrote:
> > > 
> > > 
> > > OK something for people to help with:
> > > 
> > > There is a po4a package which over-rides the version that is in
> > > RHEL-7
> > > optional. It needs to be removed from EPEL and packages depending
> > > on
> > > it need to be rebuilt against the RHEL version with a bump in
> > > NEVR
> > > get
> > > pulled on updates.
> > 
> > Well, I filed:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1443685
> > 
> > Unfortunately to match the limited arch guidelines the package
> > needs
> > to
> > be _older_ than it is now in epel.
> > 
> > I'm not sure if we can get yum to do the right thing and downgrade
> > it,
> > but we could try.
> 
> 
> ah , I built po4a to build dpkg on epel7 , but in fact po4a was added
> to centos 7 some moments before (I don't know if in RHEL7) and that
> is
> why it misses ppc64 arch [1] IIRC. BTW it also misses on ppc64, perl-
> gettext [2], maybe should be good also coordinate the fix of this
> package too. 
> If you could fix these 2 packages may the best is remove po4a from 
> epel7 repo , if it is possible ... or bump epoch on RHEL7 ... 


If Centos have the packages and RHEL not and the packages aren't
available on ppc64 because of this reason, we may think on also not
build dpkg and many debian tools on ppc64 ... 
We (reporter of bugs) miss understood the build failures, when we saw
that some package was missing , we do not notice that was only on ppc64
... and that was the confusion ... sorry . 


> Best regards, 
> 
> [1] 
> https://src.fedoraproject.org/cgit/rpms/po4a.git/tree/po4a.spec#n79
> [2]
> https://bugzilla.redhat.com/show_bug.cgi?id=1196539
> 
> > 
> > kevin
> > 
> > ___
> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > To unsubscribe send an email to epel-devel-leave@lists.fedoraprojec
> > t.
> > org
> -- 
> Sérgio M. B.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.
> org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Need to have some packages rebuilt in EPEL

2017-04-19 Thread Sérgio Basto
On Qua, 2017-04-19 at 12:03 -0600, Kevin Fenzi wrote:
> On 04/14/2017 12:05 PM, Stephen John Smoogen wrote:
> > 
> > OK something for people to help with:
> > 
> > There is a po4a package which over-rides the version that is in
> > RHEL-7
> > optional. It needs to be removed from EPEL and packages depending
> > on
> > it need to be rebuilt against the RHEL version with a bump in NEVR
> > get
> > pulled on updates.
> 
> Well, I filed:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1443685
> 
> Unfortunately to match the limited arch guidelines the package needs
> to
> be _older_ than it is now in epel.
> 
> I'm not sure if we can get yum to do the right thing and downgrade
> it,
> but we could try.


ah , I built po4a to build dpkg on epel7 , but in fact po4a was added
to centos 7 some moments before (I don't know if in RHEL7) and that is
why it misses ppc64 arch [1] IIRC. BTW it also misses on ppc64, perl-
gettext [2], maybe should be good also coordinate the fix of this
package too. 
If you could fix these 2 packages may the best is remove po4a from 
epel7 repo , if it is possible ... or bump epoch on RHEL7 ... 

Best regards, 

[1] 
https://src.fedoraproject.org/cgit/rpms/po4a.git/tree/po4a.spec#n79
[2]
https://bugzilla.redhat.com/show_bug.cgi?id=1196539

> kevin
> 
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.
> org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Debian tools on epel7

2017-03-25 Thread Sérgio Basto
Hi, 
I build for  epel 7 several Debian tools that may allow build deb
packages, now I can build some debs  in epel 7, If someone is
interested in testing let me have some feedback .

po-debconf-1.0.16-8.nmu3.el7    
smokeqt-4.14.3-7.el7    
smokegen-4.14.3-6.el7   
perl-Qt-4.14.3-5.el7    
debconf-1.5.56-6.el7    
debhelper-9.20150628-4.el7  
dpkg-1.17.27-1.el7
perl-File-FcntlLock-0.22-6.el7  
perl-Mail-Box-2.120-2.el7   
perl-User-Identity-0.96-1.el7   
perl-Object-Realize-Later-0.19-6.el7    
perl-Mail-Transport-Dbx-0.07-28.el7 
perl-Geography-Countries-2009041301-17.el7
debmirror-2.16-4.el7
dh-make-1.20140617-2.el7
pbuilder-0.228.3-2.el7  
perl-Git-Wrapper-0.047-3.el7    
perl-Parse-DebControl-2.005-10.el7  
sensible-utils-0.0.9-5.el7  
devscripts-2.16.5-1.el7
dh-autoreconf-13-2.el7  
cdbs-0.4.150-3.el7  
po-debconf-1.0.16-9.nmu3.el7
debian-keyring-2014.3-4.el7 
jetring-0.25-2.el7  
keyrings-filesystem-1-6.el7

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d90518ab91
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a0a16db403
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-73abc671aa
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f883af5b55
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-cababed3d2
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c837a68c52
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-43496f6ce3
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-2ef0ea428d
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-788760d644

also we got alien 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-bdf2b8d718

Cheers,
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Perl packaging problem

2017-02-12 Thread Sérgio Basto
Hi, 
perl-Git-Wrapper.spec doesn't build in EPEL7 because :
BuildRequires:  perl(:VERSION) >= 5.6
Ends in:
DEBUG util.py:435:  No matching package to install: 'perl(:VERSION) >= 5.6'

perl -v :
This is perl 5, version 16, subversion 3 (v5.16.3)

from: 
https://fedoraproject.org/wiki/Packaging:Perl?rd=Packaging/Perl
If you need to limit your package to a specific Perl version, use
perl(:VERSION) dependency with desired version constraint (e.g.
perl(:VERSION) >= 5.22).

But Perl 5.6.0  is a version from year 2000, so it is safe comment this
"BuildRequires", but anyone know a better solution ? 

Thanks. 
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: new DNF for everyone

2017-02-12 Thread Sérgio Basto
On Seg, 2016-08-29 at 18:06 +0200, Honza Silhan wrote:
> On Fri, Aug 26, 2016 at 9:39 PM, Orion Poplawski <or...@cora.nwra.com
> > wrote:
> 
> Hi,
> 
> > 
> > On 08/26/2016 12:26 PM, Sérgio Basto wrote:
> > > 
> > > On Sex, 2016-07-01 at 13:04 -0400, Honza Šilhan wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > DNF is in EPEL for more than one year, unfortunately there was
> > > > still
> > > > the old
> > > > DNF-0.6.4
> > > > version. Over that time in DNF were implemented a lot of great
> > > > features and
> > > > plenty of bugs
> > > > have been fixed. DNF (especially its libraries) could not be
> > > > updated
> > > > in EPEL
> > > > repository
> > > > because of its policy. Now we have prepared fresh DNF-1.1.9 for
> > > > RHEL
> > > > 7 and
> > > > CentOS 7 users
> > > > in our COPR repository [1].
> > > > 
> > > > In order to install DNF follow the instructions here [2].
> > > > 
> > > 
> > > Can't we add this to epel 7 for "Red Hat Enterprise Linux 7.3"
> > > 
> > > dnf in epel it is a bit useless, it doesn't have copr plugin for
> > > example .
> > 
> > This is the problem:
> > 
> > Available Packages
> > hawkey.x86_64  0.5.8-2.git.0.202b194.el7  rhel-7-server-
> > rpms
> > hawkey.x86_64  0.6.3-4.el7rhel-7-server-
> > beta-rpms
> > libsolv.x86_64 0.6.11-1.el7   rhel-7-server-
> > rpms
> > libsolv.x86_64 0.6.20-5.el7   rhel-7-server-
> > beta-rpms
> > 
> > libsolv.x86_64   0.6.20-4.el7.centos
> > group_rpm-software-management-dnf-stack-el7
> > hawkey.x86_64 0.6.3-4.el7.centos
> > group_rpm-software-management-dnf-stack-el7
> > 
> > But it does like it will be possible to update dnf in EPEL7 when
> > EL7.3 comes
> > out with updated hawkey and libsolv.
> 
> yes, we will update it once RHEL7.3 is out.

https://copr.fedorainfracloud.org/coprs/g/rpm-software-management/dnf-stack-el7/

works great btw 

> 
> Honza
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedorapr
> oject.org
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: new DNF for everyone

2016-08-26 Thread Sérgio Basto
On Sex, 2016-07-01 at 13:04 -0400, Honza Šilhan wrote:
> Hi,
> 
> DNF is in EPEL for more than one year, unfortunately there was still
> the old
> DNF-0.6.4
> version. Over that time in DNF were implemented a lot of great
> features and
> plenty of bugs
> have been fixed. DNF (especially its libraries) could not be updated
> in EPEL
> repository
> because of its policy. Now we have prepared fresh DNF-1.1.9 for RHEL
> 7 and
> CentOS 7 users
> in our COPR repository [1].
> 
> In order to install DNF follow the instructions here [2].
> 

Can't we add this to epel 7 for "Red Hat Enterprise Linux 7.3" 

dnf in epel it is a bit useless, it doesn't have copr plugin for
example . 

> Honza
> 
> [1] https://copr.fedorainfracloud.org/coprs/g/rpm-software-management
> /dnf-stack-el7/
> [2] http://dnf.baseurl.org/2016/07/01/fresh-dnf-for-rhel-7-and-centos
> -7/
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedorapr
> oject.org
-- 
Sérgio M. B.

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Python 2 macros on EL 6

2016-04-18 Thread Sérgio Basto
Hi, 
%{python2_sitelib} doesn't exist on epel6 ? 

from https://copr-be.cloud.fedoraproject.org/results/sergiomb/builds_fo
r_Stable_Releases/epel-6-i386/00173942-subdownloader/build.log.gz

I got: 
RPM build errors:
File must begin with "/": %{python2_sitelib}/subdownloader

which means %{python2_sitelib} is wasn't defined .

Thanks,
-- 
Sérgio M. B.

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] po4a problems

2015-04-30 Thread Sérgio Basto
Hi, epel List 
In bug 1134624 [1] someone asked to build po4a for EPEL 7.
I miss some reading and po4a is only need to be build for ppc64 ,
because in meantime CentOS built it, but only for epel 7 not for 6 and
according Dominik Mierzejewski on comment #23 ... is part of CentOS
main distribution, which is x86_64 only. So when packages came from
CentOS they are x86_64 only and this happens with po4a .
By guidelines in comment #34 , I shouldn't build it with a new version
which unfortunately happened, I built po4a-0.45 when CentOS build
po4a-0.44 , but in comment #39 I concluded that is a copy of Fedora
source which was completely out-date , so I think the best solution was
Centos updated it also . If not, we need remove po4a-0.45-3.el7 from
epel7 stable , which I haven't way/permissions to do it ... 
Suggestions please ? 

[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1134624

Thanks,
-- 
Sérgio M. B.

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel