+1. It's a build requirement for mkvtoolnix.

I think it's time to launch an AWOL process against Axel Thimm.

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

(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.

Epel maintainer is not Axel , is Dan Horák so I moving bug to Fedora epel

SCM branch request:

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

*** Bug 1153605 has been marked as a duplicate of this bug. ***

Git done (by process-git-requests).

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

po4a-0.45-3.el7 has been pushed to the Fedora EPEL 7 testing repository.

po4a-0.45-3.el7 has been pushed to the Fedora EPEL 7 stable repository.

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

> 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.

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.

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 ?

> See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1196539
This BZ is marked private - How did you access it?

(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.

(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 ?

(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 that is why I'm asking what ticket says .

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

(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.

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.

(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

(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.

> (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

(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 !

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

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).

Christopher,
Now you can build roxterm I added po4a-0.45-4.el7 to builroot , and I could build dpkg for epel7 

Thanks

ACK.

Thanks.

(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

Hey. this package is already in rhel7 - please block this package and take it away from epel7.

(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.

(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 ?

(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.

Actually po4a-0.45-3.el7 from epel7 stable must be removed too.

(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 ?

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

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.