I can no longer use ppc.koji. It says my certificate is expired:
Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate
expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake
It still works on the primary koji.
cert expires: 2011-07-04
I got an email from Jacob Yundt (see below) who has trouble posting to
the list. As it sounds interesting I am forwarding it (with him on CC).
---------- Forwarded message ----------
From: Jacob Yundt <jyundt(a)gmail.com>
Date: Wed, Jan 5, 2011 at 8:55 AM
Subject: IBM POWER5 Server
My company is in the process of e-cycling a bunch of hardware before our
next server refresh. We have an IBM 9119-595 (POWER5 64 way CPU / 0.5 TB
memory) that is scheduled to be removed before this summer. POWER5 is a
slightly outdated (POWER7 is current) but this CEC still runs production
Would anyone in the fedora project be able to use this for PPC fedora
development? If anyone is interested, please contact me off list. Full
disclosure: there will probably be a mountain of paperwork to transfer this
server but my management is interested in potentially "donating" this rather
than e-cycling (shredding?) it. I believe we are also getting rid of the
dual HMCs (7310CR3) that manage this frame as well.
Or, if this is the wrong mailing list for this, please let me know what
redhat/fedora list I should e-mail.
----- End forwarded message -----
I am currently trying to rebuild perl and it fails with never seen
It is probably caused by systemtap. If I build it without
it rebuilds fine. So I would like to build a perl package without that
line and for that I think I need more rights in koji.
I could also rebuild systemtap, but that needs a newer publican and
publican has lots of perl dependencies. So that it would make more sense
to build a temporary perl package without systemtap.
I'm watching for the process of rebuilding at ftp-stud.hs-esslingen.de
very closely and I see a lot of rebuilds of packages already built
before. Is it intentional? If not then it could indicate a potential
slowdown of the whole rebuild process due to multiple rebuilds.
Also I would like to know - could it be possible to merge the efforts
of Adrian and "official" Koji-ppc? This could boost the whole process
With best regards, Peter Lemenkov.
On Sat, Jan 8, 2011 at 7:59 AM, Josh Boyer <jwboyer(a)gmail.com> wrote:
> On Jan 7, 2011 5:42 PM, "Adrian Reber" <adrian(a)lisas.de> wrote:
>> On Sat, Jan 01, 2011 at 10:18:07AM -0500, Josh Boyer wrote:
>> > >> >> Found another problem:
>> > >> >>
>> > >> >> Traceback (most recent call last):
>> > >> >> File "/usr/sbin/kojid", line 1437, in runTask
>> > >> >> response = (handler.run(),)
>> > >> >> File "/usr/sbin/kojid", line 1513, in run
>> > >> >> return self.handler(*self.params,**self.opts)
>> > >> >> File "/usr/sbin/kojid", line 1934, in handler
>> > >> >> h = self.readSRPMHeader(srpm)
>> > >> >> File "/usr/sbin/kojid", line 2007, in readSRPMHeader
>> > >> >> h = koji.get_rpm_header(fo)
>> > >> >> File "/usr/lib/python2.6/site-packages/koji/__init__.py", line
>> > >> >> 787, in get_rpm_header
>> > >> >> hdr = ts.hdrFromFdno(fo.fileno())
>> > >> >> File "/usr/lib64/python2.6/site-packages/rpm/transaction.py",
>> > >> >> line 154, in hdrFromFdno
>> > >> >> raise rpm.error("error reading package header")
>> > >> >> error: error reading package header
>> > >> >>
>> > >> >> http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=114707
>> > >> >>
>> > >> >> Sounds like:
>> > >> >> http://lists.fedoraproject.org/pipermail/buildsys/2010-August/003224.html
>> > >>
>> > >> Yes, it does sound like that. I would have thought it to be fixed in
>> > >> koji 1.6.0 already though. Maybe not. Dan, do you know if the
>> > >> workaround is still needed in 1.6?
>> > >
>> > > Seems it's still needed, but I didn't try to push it to upstream as
>> > > the
>> > > workaround is rather a dirty hack. I'm surprised it should be needed
>> > > in
>> > > the ppc koji where the builder and hub are on the same local network
>> > > AFAIK.
>> > OK. I'll try to patch them soon. I've seen it on machines elsewhere
>> > that are sitting on the same switch even, so apparently it's not that
>> > uncommon?
>> Did you have time to apply that patch? I have seen this now with glibc
>> and gdb and I think, if this patch actually solves the problem, I need
>> it to continue with the f15 rebuilds.
> I am out of town this weekend. I will get to it Monday first thing. Dennis
> or one of the other admins might be able to do it as well.
OK, I've patched ppc-comm02 and ppc-comm01. For the record, I had to
tweak the original patch slightly to apply to 1.6.0. It's below.
@@ -48,6 +48,7 @@ import time
from ConfigParser import ConfigParser
from fnmatch import fnmatch
@@ -800,7 +801,16 @@ class BuildTask(BaseTaskHandler):
relpath = "work/%s" % srpm
opts = dict([(k, getattr(self.options, k)) for k in 'topurl','topdir'])
fo = koji.openRemoteFile(relpath, **opts)
- h = koji.get_rpm_header(fo)
+ # use a temporary file to workaround an issue where urllib2 is not able
+ # to send enough data in time to the rpm header decode function.
+ tmp = tempfile.TemporaryFile()
+ tmp.write(fo.read(1000 * 1000))
+ h = koji.get_rpm_header(tmp)
if h[rpm.RPMTAG_SOURCEPACKAGE] != 1:
raise koji.BuildError, "%s is not a source package" % srpm
As the subject says, the buildsystem is back online. It has been
upgraded to koji 1.6.0 and the two builder instances are running a new
enough kernel to build for F14 now. They should also be able to build
from the Fedora git repos as well.
I would like to thank Stephen Smoogen and Dennis Gilmore for their
extraordinary help in getting the machines rebuilt and accessible.
Let the building begin.
here are few of my thoughts before starting koji-shadow
- need to ask dgilmore for the package list that are expected to be
missing on ppc/ppc64 (ExcludeArch/ExclusiveArch), he has a script for
- because the difference between primary and ppc is so large and there
were mass rebuilds of all python (for 2.7) and perl (for 5.12) packages,
we shouldn't use the "import-noarch" feature, too new packages would be
available in the buildroots causing broken dependencies (the
"prefer-new" feature is needed to include fixed builds)
- the injected packages, that do not exist in primary koji, should have
<your_initials>.X suffix in the Release field, so they are later easily
- should we really start koji-shadow against dist-f15 or should we start
with dist-f14 first even without an intention to be complete, just to
shorten the gap before starting dist-f15
I had to apply following patch to the kernel git to get a SRPM which was
built successfully. It just disables two modules which did not compile.
I did not check if there are actual patches which fix the compile
problems. I am posting it here so that somebody who is closer to the
kernel can decide what the best solution would be.
diff --git a/config-generic b/config-generic
index 7b5630f..4566cdf 100644
@@ -644,7 +644,7 @@ CONFIG_SCSI_DC395x=m
+# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_DPT_I2O is not set
diff --git a/config-powerpc32-generic b/config-powerpc32-generic
index d230495..b62e546 100644
@@ -83,7 +83,7 @@ CONFIG_SERIAL_MPC52xx_CONSOLE=y
# CONFIG_MPC5200_WDT is not set
+# CONFIG_GEF_WDT is not set