ppc January 2011

ppc@lists.fedoraproject.org

6 participants
14 discussions

Repository @ ftp-stud.hs-esslingen.de - no new packages today.
by Peter Lemenkov 28 Feb '11

28 Feb '11

Hello All! Is everything ok with rebuild process? There was no freshly built package pushed today (13-01-2010) to the repository. -- With best regards, Peter Lemenkov.

2 3

ppc.koji trouble
by Adrian Reber 18 Jan '11

18 Jan '11

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 failure')] It still works on the primary koji. cert expires: 2011-07-04 Adrian

2 2

[jyundt@gmail.com: Fwd: IBM POWER5 Server]
by Adrian Reber 13 Jan '11

13 Jan '11

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). Adrian ---------- Forwarded message ---------- From: Jacob Yundt <jyundt(a)gmail.com> Date: Wed, Jan 5, 2011 at 8:55 AM Subject: IBM POWER5 Server To: fedora-ppc(a)lists.infradead.org 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 workloads. 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. Thanks, Jacob Yundt ----- End forwarded message -----

1 0

perl troubles
by Adrian Reber 12 Jan '11

12 Jan '11

I am currently trying to rebuild perl and it fails with never seen errors: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=116156 It is probably caused by systemtap. If I build it without -Dusedtrace='/usr/bin/dtrace' \ 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. Adrian

1 0

ftp-stud.hs-esslingen.de/pub/fedora.ppc/ppc - bogus rebuilds of already built packages
by Peter Lemenkov 11 Jan '11

11 Jan '11

Hello! 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 a lot. -- With best regards, Peter Lemenkov.

3 2

Re: ppc.koji.fedoraproject.org back online
by Josh Boyer 11 Jan '11

11 Jan '11

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. josh --- Index: koji/builder/kojid =================================================================== --- koji.orig/builder/kojid +++ koji/builder/kojid @@ -48,6 +48,7 @@ import time import traceback import xmlrpclib import zipfile +import tempfile import Cheetah.Template 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)) + tmp.seek(0) + + h = koji.get_rpm_header(tmp) + tmp.close() + fo.close() if h[rpm.RPMTAG_SOURCEPACKAGE] != 1: raise koji.BuildError, "%s is not a source package" % srpm

2 1

ppc.koji.fedoraproject.org back online
by Josh Boyer 07 Jan '11

07 Jan '11

Hi All, 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. josh

7 28

koji-shadow strategy
by Dan Horák 07 Jan '11

07 Jan '11

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 that - 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 identified - 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 Additions, opinions? Dan

4 4

1 of 3 gcc builds failed
by Adrian Reber 07 Jan '11

07 Jan '11

We have now three builds of gcc (same version) and one failed. One of my builds failed with a segmentation fault: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=115628 another one (same version, same buildroot) did not fail: http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=24400 Same version gcc build (bit different buildroot) was also successful a few days ago: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=115300 I will continue building packages, but I just wanted to mention it here. Adrian

1 0

patch for successful kernel scratch build
by Adrian Reber 05 Jan '11

05 Jan '11

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 --- a/config-generic +++ b/config-generic @@ -644,7 +644,7 @@ CONFIG_SCSI_DC395x=m CONFIG_SCSI_DEBUG=m CONFIG_SCSI_DC390T=m CONFIG_SCSI_QLA_FC=m -CONFIG_SCSI_QLA_ISCSI=m +# CONFIG_SCSI_QLA_ISCSI is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_DPT_I2O is not set CONFIG_SCSI_LPFC=m diff --git a/config-powerpc32-generic b/config-powerpc32-generic index d230495..b62e546 100644 --- a/config-powerpc32-generic +++ b/config-powerpc32-generic @@ -83,7 +83,7 @@ CONFIG_SERIAL_MPC52xx_CONSOLE=y CONFIG_SERIAL_MPC52xx_CONSOLE_BAUD=115200 # CONFIG_MPC5200_WDT is not set CONFIG_8xxx_WDT=m -CONFIG_GEF_WDT=m +# CONFIG_GEF_WDT is not set CONFIG_PPC_MPC5200_BUGFIX=y CONFIG_FEC_MPC52xx=m Adrian

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

ppc January 2011