On Sat, 12 Jul 2008, David Woodhouse wrote:
On Sat, 2008-07-12 at 00:53 +0300, Panu Matilainen wrote:
> On Fri, 11 Jul 2008, Jesse Keating wrote:
>
>> On Fri, 2008-07-11 at 15:27 -0400, Bill Nottingham wrote:
>>> Mamoru Tasaka (mtasaka(a)ioa.s.u-tokyo.ac.jp) said:
>>>> After koji began to accept jobs again, all dist-f10 ppc64 builds seem
>>>> to be failing due to some strange error?
>>>>
>>>>
http://koji.fedoraproject.org/koji/taskinfo?taskID=710447
>>>>
http://koji.fedoraproject.org/koji/taskinfo?taskID=710455
>>>>
http://koji.fedoraproject.org/koji/taskinfo?taskID=710471
>>>>
>>>> None of them have build.log and root.log say:
>>>>
>>>> DEBUG util.py:272: Executing command: ['rpm', '-Uvh',
'--nodeps',
'/builddir/build/originals/xscreensaver-5.05.90.3-3.fc10.src.rpm']
>>>> DEBUG util.py:250: memory alloc (41 bytes) returned NULL.
>>>>
>>>> Would someone investigate what is happening here?
>>>
>>> Almost certianly the new rpm broke.
>>>
>>> Bill
>>
>> Yeah, that's coming from rpm in the chroot. I can easily reproduce.
>> I'm going to untag the new rpm until we sort this out. It'll be a bit
>> before builds start working again.
>
> Ugh :-/ Can you reproduce that outside of koji, and if so, how? Is this a
> ppc64 specific thing or a more generic one?
Let me know if you need an account on a suitable machine so you can try
this in mock.
Thanks for the offer, Jarod Wilson already kindly provided me access to
ppc64 host where I can mess around :)
The good news is that I can reproduce it, and it is indeed a ppc64-only
problem. Here's what happens:
stat("/var/lib/rpm/Name", {st_mode=S_IFREG|0644, st_size=12288, ...}) = 0
open("/var/lib/rpm/Name", O_RDONLY) = 6
fcntl(6, F_SETFD, FD_CLOEXEC) = 0
read(6,
"\0\0\0\0\0\0\0\1\0\0\0\0\0\6\25a\0\0\0\10\0\0\20\0\0\10\0\0\0\0\0\0"...,
512) = 512
close(6) = 0
open("/var/lib/rpm/Name", O_RDONLY) = 6
fcntl(6, F_SETFD, FD_CLOEXEC) = 0
fstat(6, {st_mode=S_IFREG|0644, st_size=12288, ...}) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
mmap(NULL, 171798695936, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = -1 ENOMEM (Cannot allocate memory)
No wonder it fails... Now just to figure out where that comes from... but
that'll have to wait till later today/tomorrow, family is demanding
attention :)
- Panu -