Bug 1134624 - Please build po4a for EPEL7
Summary: Please build po4a for EPEL7
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: po4a
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Horák
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1153605 (view as bug list)
Depends On: 1196539 1213183
Blocks: 1149590
TreeView+ depends on / blocked
 
Reported: 2014-08-28 01:17 UTC by Christopher Meng
Modified: 2015-05-08 16:39 UTC (History)
6 users (show)

Fixed In Version: po4a-0.45-4.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-08 16:39:45 UTC
gwync: fedora-cvs+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1196539 None None None Never

Internal Links: 1196539

Description Christopher Meng 2014-08-28 01:17:45 UTC
Hi,

Please build this package for EPEL7.

Thanks.

Comment 1 Dominik 'Rathann' Mierzejewski 2014-12-17 11:48:08 UTC
+1. It's a build requirement for mkvtoolnix.

Comment 2 Ralf Corsepius 2014-12-17 12:21:24 UTC
I think it's time to launch an AWOL process against Axel Thimm.

Comment 3 Dominik 'Rathann' Mierzejewski 2014-12-17 13:37:38 UTC
This seems to affect only ppc64, as I've just done a scratch build on x86_64 and the package is available: https://kojipkgs.fedoraproject.org//work/tasks/9979/8409979/root.log

Comment 4 Ralf Corsepius 2014-12-17 14:58:05 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #3)
> This seems to affect only ppc64, as I've just done a scratch build on x86_64
> and the package is available:
> https://kojipkgs.fedoraproject.org//work/tasks/9979/8409979/root.log
Feel free to volunteer for EPEL - I am not interested in supporting EPEL.

Comment 5 Sergio Monteiro Basto 2015-01-12 22:30:11 UTC
Epel maintainer is not Axel , is Dan Horák so I moving bug to Fedora epel

Comment 6 Sergio Monteiro Basto 2015-01-13 21:25:04 UTC
SCM branch request:

Package Change Request
======================
Package Name: po4a
New Branches: epel7
Owners: sharkcz sergiomb

Comment 7 Sergio Monteiro Basto 2015-01-13 21:25:39 UTC
*** Bug 1153605 has been marked as a duplicate of this bug. ***

Comment 8 Gwyn Ciesla 2015-01-14 11:59:14 UTC
Git done (by process-git-requests).

Comment 9 Fedora Update System 2015-01-17 11:48:25 UTC
po4a-0.45-3.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/po4a-0.45-3.el7

Comment 10 Fedora Update System 2015-01-17 19:17:25 UTC
po4a-0.45-3.el7 has been pushed to the Fedora EPEL 7 testing repository.

Comment 11 Fedora Update System 2015-02-14 02:53:48 UTC
po4a-0.45-3.el7 has been pushed to the Fedora EPEL 7 stable repository.

Comment 12 Christopher Meng 2015-02-16 10:37:33 UTC
Oops!

Building roxterm which requires po4a, failed at dependency issue in buildroot:

DEBUG util.py:366:  Getting requirements for roxterm-2.9.5-1.el7.src
DEBUG util.py:366:   --> dbus-glib-devel-0.100-7.el7.ppc64
DEBUG util.py:366:   --> desktop-file-utils-0.21-4.el7.ppc64
DEBUG util.py:366:   --> gtk3-devel-3.8.8-5.el7.ppc64
DEBUG util.py:366:   --> libglade2-devel-2.6.4-11.el7.ppc64
DEBUG util.py:366:   --> libSM-devel-1.2.1-7.el7.ppc64
DEBUG util.py:366:   --> libtool-2.4.2-20.el7.ppc64
DEBUG util.py:366:   --> po4a-0.45-3.el7.noarch
DEBUG util.py:366:   --> 1:python-lockfile-0.9.1-4.el7.noarch
DEBUG util.py:366:   --> vte3-devel-0.34.6-3.el7.ppc64
DEBUG util.py:366:   --> xmlto-0.0.25-7.el7.ppc64
DEBUG util.py:366:   --> 1:control-center-3.8.6-15.el7.ppc64
DEBUG util.py:366:  Error: Package: po4a-0.45-3.el7.noarch (build)
DEBUG util.py:366:             Requires: perl(Locale::gettext) >= 1.01
DEBUG util.py:366:   You could try using --skip-broken to work around the problem
DEBUG util.py:366:   You could try running: rpm -Va --nofiles --nodigest

Comment 13 Ralf Corsepius 2015-02-16 12:33:41 UTC
> Oops!
> 
> Building roxterm which requires po4a, failed at dependency issue in
> buildroot:

Why don't you guys test your stuff before pushing it into EPEL, esp. when knowing the automated package dep checking stuff is basically dysfunctional?

EPEL already has accumulated quite a number of packages which are broken for similar careless works, cf. https://lists.fedoraproject.org/pipermail/perl-devel/2015-February/date.html
ff.

Comment 14 Dan Horák 2015-02-16 14:13:39 UTC
This problem seems to be caused by different content between x86_64 and ppc64 versions of RHEL-7. Christopher, please open a bug against RHEL-7 asking for inclusion of perl-gettext in the ppc64 version too.

Comment 15 Sergio Monteiro Basto 2015-02-17 18:18:35 UTC
ah it is ppc64 problem , I test it carefully 

why ppc64 don't have things that have x64_86 ? shouldn't be the same content ?

Comment 16 Ralf Corsepius 2015-02-26 08:55:50 UTC
> See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1196539
This BZ is marked private - How did you access it?

Comment 17 Christopher Meng 2015-02-26 10:46:13 UTC
(In reply to Ralf Corsepius from comment #16)
> > See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1196539
> This BZ is marked private - How did you access it?

I reported this but marked as private then... That ticket was assigned to Red Hat PM team.

Comment 18 Sergio Monteiro Basto 2015-02-26 15:49:08 UTC
(In reply to Christopher Meng from comment #17)
> (In reply to Ralf Corsepius from comment #16)
> > > See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1196539
> > This BZ is marked private - How did you access it?
> 
> I reported this but marked as private then... That ticket was assigned to
> Red Hat PM team.

and what ticket says ?

Comment 19 Ralf Corsepius 2015-02-26 16:00:17 UTC
(In reply to Sergio Monteiro Basto from comment #18)

> and what ticket says ?
"You are not authorized to access bug #1196539."

=> Christopher is trolling.

Comment 20 Sergio Monteiro Basto 2015-02-26 16:02:48 UTC
No that is why I'm asking what ticket says .

Comment 21 Sergio Monteiro Basto 2015-02-26 17:19:20 UTC
yum install "perl(Locale::gettext)"

try install perl-gettext

Looking for perl-gettext: https://apps.fedoraproject.org/packages/perl-gettext

on http://pkgs.fedoraproject.org/cgit/perl-gettext.git/tree/ I don't see any  ExcludeArch ppc64 

why we don't have perl-gettext on ppc64 ? 

I don't see any bug with perl-gettext and ppc64 [1]



[1] https://bugzilla.redhat.com/buglist.cgi?component=perl-gettext

Comment 22 Ralf Corsepius 2015-02-26 18:05:06 UTC
(In reply to Sergio Monteiro Basto from comment #21)
> why we don't have perl-gettext on ppc64 ? 
Because nobody has built it?

This package own by me and I do not support (Actually boycott) RHEL.

Comment 23 Dominik 'Rathann' Mierzejewski 2015-02-26 18:31:03 UTC
Ralf, that was not an excellent thing to write.

Sergio, I can see that perl-gettext is part of CentOS main distribution, which is x86_64 only, so you can request a ppc64-only EPEL7 branch.

Comment 24 Sergio Monteiro Basto 2015-02-26 19:16:20 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #23)
> Sergio, I can see that perl-gettext is part of CentOS main distribution,
> which is x86_64 only, so you can request a ppc64-only EPEL7 branch.

ah! you solve this mystery ... .

(In reply to Ralf Corsepius from comment #22) 
> This package own by me and I do not support (Actually boycott) RHEL.
This is not about RHEL is about ppc64 


For all: 

I haven't time for maintain things for ppc64 ... maybe contact ppc group 

http://fedoraproject.org/wiki/Architectures/PowerPC

Comment 25 Ralf Corsepius 2015-02-26 21:39:13 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #23)
> Ralf, that was not an excellent thing to write.
What is you problem? I have never supported RHEL nor built any package for EPEL ever, because I consider EPEL to be a RH vehicle to out-source packages.

I am saying so ever since EPEL exists and will repeat this when being asked.

Provided, how you are reacting and provided who Sergio has ignored the fact I have been de-facto maintaineed po4a for years, when po4a was orphaned. I am stepping down as Fedora po4a maintainer.

> Sergio, I can see that perl-gettext is part of CentOS main distribution,
> which is x86_64 only, so you can request a ppc64-only EPEL7 branch.
That's another problem, which renders supporting EPEL a nightmare.

Comment 26 Sergio Monteiro Basto 2015-02-26 23:52:37 UTC
> (In reply to Ralf Corsepius from comment #22) 
> This is not about RHEL is about ppc64 

ops, is about ppc64 on RHEL el7 ? 

Also po4a for ppc64 on Fedora builds well [1] 

[1] http://ppc.koji.fedoraproject.org/koji/packageinfo?packageID=6582

Comment 27 Sergio Monteiro Basto 2015-04-19 21:33:37 UTC
(In reply to Christopher Meng from comment #12)
> Oops!
> 
> Building roxterm which requires po4a, failed at dependency issue in
> buildroot:
> 
> DEBUG util.py:366:  Getting requirements for roxterm-2.9.5-1.el7.src
> DEBUG util.py:366:   --> dbus-glib-devel-0.100-7.el7.ppc64
> DEBUG util.py:366:   --> desktop-file-utils-0.21-4.el7.ppc64
> DEBUG util.py:366:   --> gtk3-devel-3.8.8-5.el7.ppc64
> DEBUG util.py:366:   --> libglade2-devel-2.6.4-11.el7.ppc64
> DEBUG util.py:366:   --> libSM-devel-1.2.1-7.el7.ppc64
> DEBUG util.py:366:   --> libtool-2.4.2-20.el7.ppc64
> DEBUG util.py:366:   --> po4a-0.45-3.el7.noarch
> DEBUG util.py:366:   --> 1:python-lockfile-0.9.1-4.el7.noarch
> DEBUG util.py:366:   --> vte3-devel-0.34.6-3.el7.ppc64
> DEBUG util.py:366:   --> xmlto-0.0.25-7.el7.ppc64
> DEBUG util.py:366:   --> 1:control-center-3.8.6-15.el7.ppc64
> DEBUG util.py:366:  Error: Package: po4a-0.45-3.el7.noarch (build)
> DEBUG util.py:366:             Requires: perl(Locale::gettext) >= 1.01
> DEBUG util.py:366:   You could try using --skip-broken to work around the
> problem
> DEBUG util.py:366:   You could try running: rpm -Va --nofiles --nodigest

Hi 

I'll remove Requires: perl(Locale::gettext) >= 1.01 for epel. In package spec it says that it is optional, but package is quite useless without

anyway I got same problem building dpkg for epel7 and 
http://koji.fedoraproject.org/koji/buildinfo?buildID=210853
shows perl-gettext-1.05-16.el6 built on all arches . 

Reopen it !

Comment 28 Fedora Update System 2015-04-19 22:12:44 UTC
po4a-0.45-4.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/po4a-0.45-4.el7

Comment 29 Fedora Update System 2015-04-20 18:38:04 UTC
Package po4a-0.45-4.el7:
* should fix your issue,
* was pushed to the Fedora EPEL 7 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing po4a-0.45-4.el7'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5882/po4a-0.45-4.el7
then log in and leave karma (feedback).

Comment 30 Sergio Monteiro Basto 2015-04-21 02:02:37 UTC
Christopher,
Now you can build roxterm I added po4a-0.45-4.el7 to builroot , and I could build dpkg for epel7 

Thanks

Comment 31 Christopher Meng 2015-04-21 05:10:32 UTC
ACK.

Thanks.

Comment 32 Christopher Meng 2015-04-21 05:15:39 UTC
(In reply to Ralf Corsepius from comment #19)
> (In reply to Sergio Monteiro Basto from comment #18)
> 
> > and what ticket says ?
> "You are not authorized to access bug #1196539."
> 
> => Christopher is trolling.

No, trolling with you is useless I think. I think a meme is better for you. But I have limited time now.

Proof: http://imgur.com/1qtuGZ1

Comment 33 Tuomo Soini 2015-04-23 09:25:24 UTC
Hey. this package is already in rhel7 - please block this package and take it away from epel7.

Comment 34 Dominic Cleal 2015-04-23 09:36:51 UTC
(In reply to Tuomo Soini from comment #33)
> Hey. this package is already in rhel7 - please block this package and take
> it away from epel7.

It's only present for x86_64, not ppc64, so building it in epel7 is mostly correct, AIUI.

It seems that the policy for limited arch packages hasn't been followed fully though - the package (po4a-0.45-4) is newer than RHEL's (po4a-0.44-10.el7), which is going to mean EPEL7's version is used on x86_64.

http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages states that the version must be kept older than RHEL's, so that would mean shipping 0.44 and adding the leading zero to the release field.

Comment 35 Sergio Monteiro Basto 2015-04-23 15:20:35 UTC
(In reply to Dominic Cleal from comment #34)
> (In reply to Tuomo Soini from comment #33)
> > Hey. this package is already in rhel7 - please block this package and take
> > it away from epel7.
> 
> It's only present for x86_64, not ppc64, so building it in epel7 is mostly
> correct, AIUI.
> 
> It seems that the policy for limited arch packages hasn't been followed
> fully though - the package (po4a-0.45-4) is newer than RHEL's
> (po4a-0.44-10.el7), which is going to mean EPEL7's version is used on x86_64.
> 
> http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages states
> that the version must be kept older than RHEL's, so that would mean shipping
> 0.44 and adding the leading zero to the release field.

yeah , I think I will give up build whatever on EPEL , too much confuse for me. 

(In reply to Dominik 'Rathann' Mierzejewski from comment #23) 
> Sergio, I can see that perl-gettext is part of CentOS main distribution,
> which is x86_64 only, so you can request a ppc64-only EPEL7 branch.

why rhel7 doesn't build those package for ppc64 ? build a ppc64-only is a nonsense work . 

So what I should do now ? remove po4a-0.45-4 from updates-testing ?

Comment 36 Dominic Cleal 2015-04-23 15:27:08 UTC
(In reply to Sergio Monteiro Basto from comment #35)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #23) 
> > Sergio, I can see that perl-gettext is part of CentOS main distribution,
> > which is x86_64 only, so you can request a ppc64-only EPEL7 branch.
> 
> why rhel7 doesn't build those package for ppc64 ? build a ppc64-only is a
> nonsense work . 

I didn't get to the bottom of it, but it's likely a dependency of a feature such as virtualisation that's only available on x86_64, so the entire dependency tree isn't built for ppc64.  (A guess, I haven't confirmed.)

> So what I should do now ? remove po4a-0.45-4 from updates-testing ?

I'd recommend this (I think there's a button to withdraw it through bodhi) and then if you're still willing, to build 0.44-0.10 or similar instead.

Comment 37 Tuomo Soini 2015-04-23 17:25:57 UTC
Actually po4a-0.45-3.el7 from epel7 stable must be removed too.

Comment 38 Sergio Monteiro Basto 2015-04-24 13:25:11 UTC
(In reply to Tuomo Soini from comment #37)
> Actually po4a-0.45-3.el7 from epel7 stable must be removed too.

I haven't permissions to, I will report this issue on epel mailing list, to see what will be the solution. 
What do you think on build dependencies ( at least mkvtoolnix, roxterm and dpkg) only on x86 ?

Comment 39 Sergio Monteiro Basto 2015-04-26 04:19:05 UTC
For reference only on 2014-06-09 , we got po4a only on Centos 7 [1] and not on other Centos version.

The po4a-0.44-10.el7, by changelog, is a copy of po4a-0.44-9 and not have po4a-0.44-10 fixes, dated of 2013-07-30 ... 

[1] https://git.centos.org/tree/rpms!po4a.git/refs!heads!c7

Comment 40 Fedora Update System 2015-05-08 16:39:45 UTC
po4a-0.45-4.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.