I just had a weird failure on a koji builder:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8776617
The SRPM creation step failed, with this output:
error: parse error in expression error: /builddir/build/SPECS/libpuma.spec:119: bad %if condition Building target platforms: noarch Building for target noarch Child return code was: 1 EXCEPTION: Command failed. See logs for output.
It is complaining about this line in the spec file:
%if %{__isa_bits} == 64
and, from the mention of noarch, my guess is that the complaint is triggered because whatever is doing the parsing thinks this is a noarch package. It is not. It is an archful package, with a noarch -doc subpackage. What component is doing this parsing? Was it changed recently? Because that same construct in the spec file didn't cause a problem the last time I built this package. Also, the package builds without trouble in mock. Thanks,
Jerry James wrote:
I just had a weird failure on a koji builder:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8776617
The SRPM creation step failed, with this output:
error: parse error in expression error: /builddir/build/SPECS/libpuma.spec:119: bad %if condition Building target platforms: noarch Building for target noarch Child return code was: 1 EXCEPTION: Command failed. See logs for output.
It is complaining about this line in the spec file:
%if %{__isa_bits} == 64
Maybe try a safer comparison when/if __isa_bits is undefined? something like:
%if "%{?__isa_bits}" == "64"
instead?
-- Rex
On Thu, Jan 29, 2015 at 8:29 PM, Rex Dieter rdieter@math.unl.edu wrote:
Maybe try a safer comparison when/if __isa_bits is undefined? something like:
%if "%{?__isa_bits}" == "64"
instead?
I have been assured that %__isa_bits is always defined, except for noarch builds:
https://lists.fedoraproject.org/pipermail/devel/2014-October/203331.html
That's what this problem looks like to me: something has erroneously concluded that this is a noarch build. I just don't know what that something is, or why it reached such a conclusion. Thanks,
On Thu, Jan 29, 2015 at 8:43 PM, Jerry James loganjerry@gmail.com wrote:
I have been assured that %__isa_bits is always defined, except for noarch builds:
https://lists.fedoraproject.org/pipermail/devel/2014-October/203331.html
That's what this problem looks like to me: something has erroneously concluded that this is a noarch build. I just don't know what that something is, or why it reached such a conclusion. Thanks,
createSRPMfromSCM operations are always noarch and can performed on any primary architecture.
In general, you should always use %{?foo} syntax for anything that will be parsed at createSRPMfromSCM time (e.g. in %if conditionals and anything above %prep), unless of course it is defined with %global in your spec file. There's a lot of stuff that's missing during SRPM creation time...
-T.C.
On Thu, Jan 29, 2015 at 9:36 PM, T.C. Hollingsworth tchollingsworth@gmail.com wrote:
createSRPMfromSCM operations are always noarch and can performed on any primary architecture.
In general, you should always use %{?foo} syntax for anything that will be parsed at createSRPMfromSCM time (e.g. in %if conditionals and anything above %prep), unless of course it is defined with %global in your spec file. There's a lot of stuff that's missing during SRPM creation time...
Thanks, but there is nothing wrong with the conditional. That particular conditional is used [1] in lots [2] of [3] spec [4] files [5], and worked the last time I built this package. The problem here is that *something* is erroneously concluding that the package I am trying to build is noarch. It isn't. It has a noarch subpackage, but the package itself is archful. What is the something that is coming to this wrong conclusion?
References: [1] https://apps.fedoraproject.org/packages/NearTree-devel/sources/spec [2] https://apps.fedoraproject.org/packages/rasmol/sources/spec [3] https://apps.fedoraproject.org/packages/Box2D/sources/spec [4] https://apps.fedoraproject.org/packages/python-webm/sources/spec [5] https://apps.fedoraproject.org/packages/libpuzzle/sources/spec
On Fri, 30 Jan 2015 09:47:52 -0700 Jerry James loganjerry@gmail.com wrote:
Thanks, but there is nothing wrong with the conditional. That particular conditional is used [1] in lots [2] of [3] spec [4] files [5], and worked the last time I built this package. The problem here is that *something* is erroneously concluding that the package I am trying to build is noarch. It isn't. It has a noarch subpackage, but the package itself is archful. What is the something that is coming to this wrong conclusion?
I'm really not sure, but a scratch build here works fine: https://koji.fedoraproject.org/koji/taskinfo?taskID=8784062
Is there any changes to your local koji client config? You are just doing a 'fedpkg build' ?
Would you like me to try and re-run it from here?
kevin
Eek, sorry, got busy and forgot about this...
On Fri, Jan 30, 2015 at 10:49 AM, Kevin Fenzi kevin@scrye.com wrote:
I'm really not sure, but a scratch build here works fine: https://koji.fedoraproject.org/koji/taskinfo?taskID=8784062
Is there any changes to your local koji client config?
As far as I can remember, the only change I have made is to add anon_retry = yes. This is what /etc/koji.conf currently contains:
[koji]
;configuration for koji cli tool
;url of XMLRPC server server = http://koji.fedoraproject.org/kojihub
;url of web interface weburl = http://koji.fedoraproject.org/koji
;url of package download site topurl = https://kojipkgs.fedoraproject.org/
;path to the koji top directory ;topdir = /mnt/koji
;configuration for Kerberos authentication
;the service name of the principal being used by the hub ;krbservice = host
;configuration for SSL authentication
;client certificate cert = ~/.fedora.cert
;certificate of the CA that issued the client certificate ca = ~/.fedora-server-ca.cert
;certificate of the CA that issued the HTTP server certificate serverca = ~/.fedora-server-ca.cert
anon_retry = yes
You are just doing a 'fedpkg build' ?
Yes.
Would you like me to try and re-run it from here?
No, the package doesn't build properly with gcc 5.0. I need to figure out why and fix it before we try another build.
Also, note that somebody else is now seeing this problem (see gil's message from a few minutes ago), so something definitely needs to be fixed somewhere. It would be good to track down the actual source of the problem. I'll jump onto gil's thread and comment.
Il 12/02/2015 16:50, Jerry James ha scritto:
Eek, sorry, got busy and forgot about this...
On Fri, Jan 30, 2015 at 10:49 AM, Kevin Fenzi kevin@scrye.com wrote:
I'm really not sure, but a scratch build here works fine: https://koji.fedoraproject.org/koji/taskinfo?taskID=8784062
Is there any changes to your local koji client config?
as i wrote in my e-mail titled "jni libraries fails in koji" i have the same problem i haven't done any changes in koji client config contains [koji]
;configuration for koji cli tool
;url of XMLRPC server server = http://koji.fedoraproject.org/kojihub
;url of web interface weburl = http://koji.fedoraproject.org/koji
;url of package download site topurl = https://kojipkgs.fedoraproject.org/
;path to the koji top directory ;topdir = /mnt/koji
;configuration for Kerberos authentication
;the service name of the principal being used by the hub ;krbservice = host
;configuration for SSL authentication
;client certificate cert = ~/.fedora.cert
;certificate of the CA that issued the client certificate ca = ~/.fedora-server-ca.cert
;certificate of the CA that issued the HTTP server certificate serverca = ~/.fedora-server-ca.cert
As far as I can remember, the only change I have made is to add anon_retry = yes. This is what /etc/koji.conf currently contains:
[koji]
;configuration for koji cli tool
;url of XMLRPC server server = http://koji.fedoraproject.org/kojihub
;url of web interface weburl = http://koji.fedoraproject.org/koji
;url of package download site topurl = https://kojipkgs.fedoraproject.org/
;path to the koji top directory ;topdir = /mnt/koji
;configuration for Kerberos authentication
;the service name of the principal being used by the hub ;krbservice = host
;configuration for SSL authentication
;client certificate cert = ~/.fedora.cert
;certificate of the CA that issued the client certificate ca = ~/.fedora-server-ca.cert
;certificate of the CA that issued the HTTP server certificate serverca = ~/.fedora-server-ca.cert
anon_retry = yes
You are just doing a 'fedpkg build' ?
Yes.
Would you like me to try and re-run it from here?
No, the package doesn't build properly with gcc 5.0. I need to figure out why and fix it before we try another build.
Also, note that somebody else is now seeing this problem (see gil's message from a few minutes ago), so something definitely needs to be fixed somewhere. It would be good to track down the actual source of the problem. I'll jump onto gil's thread and comment.
On Thu, Feb 12, 2015 at 9:28 AM, gil puntogil@libero.it wrote:
as i wrote in my e-mail titled "jni libraries fails in koji" i have the same problem i haven't done any changes in koji client config
I tried the csdp build again this morning to see if perhaps the problem is nondeterministic. It failed again:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8921616
Does anybody have any idea at all why some archful packages are being treated as if they were noarch? It doesn't affect mock builds, just koji builds.
Jerry James wrote on 02/14/2015 12:23 AM:
On Thu, Feb 12, 2015 at 9:28 AM, gil puntogil@libero.it wrote:
as i wrote in my e-mail titled "jni libraries fails in koji" i have the same problem i haven't done any changes in koji client config
I tried the csdp build again this morning to see if perhaps the problem is nondeterministic. It failed again:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8921616
Does anybody have any idea at all why some archful packages are being treated as if they were noarch? It doesn't affect mock builds, just koji builds.
Note that this fails on "buildSRPMFromSCM", i.e. when creating srpm, and not on "buildArch" (armv7hl, i686, x86_64), where rpmbuild the newly created srpm is executed.
So when using mock, usually srpm is already there on your local disc. But on koji, first koji tries to "create srpm" from SCM (git repository), and when creating srpm, koji uses:
/usr/bin/rpmbuild -bs --target noarch --nodeps foo.spec
i.e. creating srpm is always done as noarch. Then after creating srpm, arch-dependent (sometimes independent) rpmbuild foo.src.rpm is executed.
Regards, Mamoru
On Sat, 14 Feb 2015 00:45:50 +0900 Mamoru TASAKA mtasaka@fedoraproject.org wrote:
Note that this fails on "buildSRPMFromSCM", i.e. when creating srpm, and not on "buildArch" (armv7hl, i686, x86_64), where rpmbuild the newly created srpm is executed.
So when using mock, usually srpm is already there on your local disc. But on koji, first koji tries to "create srpm" from SCM (git repository), and when creating srpm, koji uses:
/usr/bin/rpmbuild -bs --target noarch --nodeps foo.spec
i.e. creating srpm is always done as noarch. Then after creating srpm, arch-dependent (sometimes independent) rpmbuild foo.src.rpm is executed.
This is not the case. Please see the earlier posts in this thread. ;)
I think this might be a mock bug.
http://koji.fedoraproject.org/koji/taskinfo?taskID=8921617
% koji mock-config --task 8921617 | grep target config_opts['target_arch'] = 'x86_64'
but yet:
ENTER do(['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target noarch --nodeps /builddir/build/SPECS/csdp.spec'], chrootPath='/var/lib/mock/f23-build-2951435-454610/root'shell=FalseprintOutput=Falseenv={'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\x1b]0;<mock-chroot>\x07<mock-chroot>"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}gid=425user='mockbuild'timeout=86400logger=<mockbuild.trace_decorator.getLog object at 0x7fdce02535d0>uid=1000) Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target noarch --nodeps /builddir/build/SPECS/csdp.spec'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\x1b]0;<mock-chroot>\x07<mock-chroot>"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'} and shell False
Can you file a bug against mock and we can see if the mock maintainers can track it down?
kevin
a fix for this problem is: (see http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-servic... ) # rpmbuild < 4.6 support %if ! 0%{?__isa_bits} %ifarch x86_64 ia64 ppc64 sparc64 s390x alpha ppc64le aarch64 %global __isa_bits 64 %else %global __isa_bits 32 %endif %endif
Il 13/02/2015 19:11, Kevin Fenzi ha scritto:
On Sat, 14 Feb 2015 00:45:50 +0900 Mamoru TASAKA mtasaka@fedoraproject.org wrote:
Note that this fails on "buildSRPMFromSCM", i.e. when creating srpm, and not on "buildArch" (armv7hl, i686, x86_64), where rpmbuild the newly created srpm is executed.
So when using mock, usually srpm is already there on your local disc. But on koji, first koji tries to "create srpm" from SCM (git repository), and when creating srpm, koji uses:
/usr/bin/rpmbuild -bs --target noarch --nodeps foo.spec
i.e. creating srpm is always done as noarch. Then after creating srpm, arch-dependent (sometimes independent) rpmbuild foo.src.rpm is executed.
This is not the case. Please see the earlier posts in this thread. ;)
I think this might be a mock bug.
http://koji.fedoraproject.org/koji/taskinfo?taskID=8921617
% koji mock-config --task 8921617 | grep target config_opts['target_arch'] = 'x86_64'
but yet:
ENTER do(['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target noarch --nodeps /builddir/build/SPECS/csdp.spec'], chrootPath='/var/lib/mock/f23-build-2951435-454610/root'shell=FalseprintOutput=Falseenv={'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\x1b]0;<mock-chroot>\x07<mock-chroot>"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}gid=425user='mockbuild'timeout=86400logger=<mockbuild.trace_decorator.getLog object at 0x7fdce02535d0>uid=1000) Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target noarch --nodeps /builddir/build/SPECS/csdp.spec'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\x1b]0;<mock-chroot>\x07<mock-chroot>"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'} and shell False
Can you file a bug against mock and we can see if the mock maintainers can track it down?
kevin
On Fri, 13 Feb 2015 23:44:18 +0100 gil puntogil@libero.it wrote:
a fix for this problem is: (see http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-servic... )
Well, this doesn't seem like a fix, but more of a workaround and a bit prone to failure if new arches are added, etc.
# rpmbuild < 4.6 support
What happened in 4.6?
%if ! 0%{?__isa_bits} %ifarch x86_64 ia64 ppc64 sparc64 s390x alpha ppc64le aarch64 %global __isa_bits 64 %else %global __isa_bits 32 %endif %endif
kevin
Il 15/02/2015 22:01, Kevin Fenzi ha scritto:
On Fri, 13 Feb 2015 23:44:18 +0100 gil puntogil@libero.it wrote:
a fix for this problem is: (see http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-servic... )
Well, this doesn't seem like a fix, but more of a workaround and a bit prone to failure if new arches are added, etc.
yes, ... newer arches? in the case of the library that i had to repackage (|leveldbjni|) only supports x86 and x86_64 arch es as in most of the cases, and i do not have hardware/devices different from those required ...
# rpmbuild < 4.6 support
What happened in 4.6?
i don't remember/know. i just copied the text as an example.
%if ! 0%{?__isa_bits} %ifarch x86_64 ia64 ppc64 sparc64 s390x alpha ppc64le aarch64 %global __isa_bits 64 %else %global __isa_bits 32 %endif %endif
kevin
regards gil
On Fri, Feb 13, 2015 at 2:44 PM, gil puntogil@libero.it wrote:
a fix for this problem is: (see http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-servic...
) # rpmbuild < 4.6 support %if ! 0%{?__isa_bits} %ifarch x86_64 ia64 ppc64 sparc64 s390x alpha ppc64le aarch64 %global __isa_bits 64 %else %global __isa_bits 32 %endif %endif
I've just run into this problem with the sphinx build - which built fine with 2.2.7-1 on January 21st - which was before this thread started. Is the workaround the recommendation? Was a mock bug created?
I found the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1141513
On Sun, Mar 29, 2015 at 5:02 PM, Gerald B. Cox gbcox@bzb.us wrote:
On Fri, Feb 13, 2015 at 2:44 PM, gil puntogil@libero.it wrote:
a fix for this problem is: (see http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-servic...
) # rpmbuild < 4.6 support %if ! 0%{?__isa_bits} %ifarch x86_64 ia64 ppc64 sparc64 s390x alpha ppc64le aarch64 %global __isa_bits 64 %else %global __isa_bits 32 %endif %endif
I've just run into this problem with the sphinx build - which built fine with 2.2.7-1 on January 21st - which was before this thread started. Is the workaround the recommendation? Was a mock bug created?
Sorry, upon closer review doesn't look like that quite matches. Couldn't find a bug... if someone knows of one, please let me know, otherwise I'll create one. I used the workaround, and that worked fine btw; but doesn't seem like it should be the solution.
Thanks!
On Sun, Mar 29, 2015 at 5:32 PM, Gerald B. Cox gbcox@bzb.us wrote:
I found the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1141513
On Sun, Mar 29, 2015 at 5:02 PM, Gerald B. Cox gbcox@bzb.us wrote:
On Fri, Feb 13, 2015 at 2:44 PM, gil puntogil@libero.it wrote:
a fix for this problem is: (see http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-servic...
) # rpmbuild < 4.6 support %if ! 0%{?__isa_bits} %ifarch x86_64 ia64 ppc64 sparc64 s390x alpha ppc64le aarch64 %global __isa_bits 64 %else %global __isa_bits 32 %endif %endif
I've just run into this problem with the sphinx build - which built fine with 2.2.7-1 on January 21st - which was before this thread started. Is the workaround the recommendation? Was a mock bug created?
-
Gerald B. Cox -
gil -
Jerry James -
Kevin Fenzi -
Mamoru TASAKA -
Rex Dieter -
T.C. Hollingsworth