9:20 p.m.
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
http://www.jamezone.org/
9:29 p.m.
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
9:43 p.m.
On Thu, Jan 29, 2015 at 8:29 PM, Rex Dieter <rdieter(a)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,
--
Jerry James
http://www.jamezone.org/
10:36 p.m.
On Thu, Jan 29, 2015 at 8:43 PM, Jerry James <loganjerry(a)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.
10:47 a.m.
On Thu, Jan 29, 2015 at 9:36 PM, T.C. Hollingsworth
<tchollingsworth(a)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
--
Jerry James
http://www.jamezone.org/
11:49 a.m.
On Fri, 30 Jan 2015 09:47:52 -0700
Jerry James <loganjerry(a)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
9:50 a.m.
Eek, sorry, got busy and forgot about this...
On Fri, Jan 30, 2015 at 10:49 AM, Kevin Fenzi <kevin(a)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.
--
Jerry James
http://www.jamezone.org/
10:28 a.m.
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(a)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.
9:23 a.m.
On Thu, Feb 12, 2015 at 9:28 AM, gil <puntogil(a)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
http://www.jamezone.org/
9:45 a.m.
Jerry James wrote on 02/14/2015 12:23 AM:
On Thu, Feb 12, 2015 at 9:28 AM, gil <puntogil(a)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
12:11 p.m.
On Sat, 14 Feb 2015 00:45:50 +0900
Mamoru TASAKA <mtasaka(a)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
4:44 p.m.
a fix for this problem is:
(see
http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-ser...
)
# 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(a)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
3:01 p.m.
On Fri, 13 Feb 2015 23:44:18 +0100
gil <puntogil(a)libero.it> wrote:
a fix for this problem is:
(see
http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-ser...
)
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
3:31 p.m.
Il 15/02/2015 22:01, Kevin Fenzi ha scritto:
On Fri, 13 Feb 2015 23:44:18 +0100
gil <puntogil(a)libero.it> wrote:
> a fix for this problem is:
> (see
>
http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-ser...
> )
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
7:02 p.m.
On Fri, Feb 13, 2015 at 2:44 PM, gil <puntogil(a)libero.it> wrote:
a fix for this problem is:
(see
http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-ser...
)
# 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?
7:32 p.m.
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(a)bzb.us> wrote:
On Fri, Feb 13, 2015 at 2:44 PM, gil <puntogil(a)libero.it> wrote:
> a fix for this problem is:
> (see
>
http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-ser...
>
> )
> # 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?
8:01 p.m.
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(a)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(a)bzb.us> wrote:
>
> On Fri, Feb 13, 2015 at 2:44 PM, gil <puntogil(a)libero.it> wrote:
>
>> a fix for this problem is:
>> (see
>>
http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-ser...
>>
>> )
>> # 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?
>
3307
days inactive
3366
days old
16 comments
7 participants
participants (7)
-
Gerald B. Cox -
gil -
Jerry James -
Kevin Fenzi -
Mamoru TASAKA -
Rex Dieter -
T.C. Hollingsworth