buildsys November 2009

buildsys@lists.fedoraproject.org

16 participants
12 discussions

php.spec -> "configure" needs to be removed before "buildconf" is called?!
by Tim Richert 27 Nov '09

27 Nov '09

I've tried building current PHP (5.3.1) with suhosin-patch. This fails with > checking for libedit readline replacement... yes > configure: error: Please reinstall libedit - I cannot find readline.h I figured out that the php-5.3.0-libedit.patch patches config.m4 and changes {/usr/local,/usr}/include/readline/readline.h into {/usr/local,/usr}/include/editline/readline.h The suhosin-patch patches ./configure directly but seems to also patch the according m4-files. If I've got i right > ./buildconf --force is called during the build to recreate ./configure to apply the patches made to the m4-files. It seems as if ./configure is only being recreated for sure, if it doesn't exist when buildconf is called. Can someone confirm that and if so wouldn't the spec-file then needed to be adjusted? If you delete ./configure before calling ./buildconf PHP builds fine with the suhosin-patch. I have changed the following > # Regenerate configure scripts (patches change config.m4's) > ./buildconf --force into > # Regenerate configure scripts (patches change config.m4's) > rm configure > ./buildconf --force in the spec-file. Can someone confirm that this wouldn't affect anything else and could so be applied to the current spec-file? Thanks! Greets, Tim

1 0

everytime serveral packages built, then the package build tasks left alawys open or free
by peng chen 25 Nov '09

25 Nov '09

Recently , I encountered with a problem of building as follow : When I request 4 or 5 packages for building at a time , my buildsys run normally. but when I request 20 (for example), It just builds 4 or 5 of them and then the left always stay in open or free state. then, I cancel those then resubmit 4 or 5 packages of them , they are built normally and quickly . Additionally, I succeed to build hundreds of packages at a time before. Thus, I guess whether the koji-hub stop scheduling or build hosts outage? Thanks!

2 1

Mergerepos command error: Cannot allocate memory/ RPMDB open failed
by rotru＠br.ibm.com 25 Nov '09

25 Nov '09

Guy, I have had the following problem frequently. I'm not sure if I have a memory problem or a rmp db problem. Has anyone ever seen this ? I'm running koji on a Fedora 11, with createrepo-0.9.7-7.fc11.noarch yum-3.2.23-3.fc11.noarch rpm-4.7.1-3.fc11.x86_64 $ /usr/libexec/kojid/mergerepos -a i386 -b /mnt/koji/repos/oc-fedora12-build/742/i386/blocklist -o /tmp/koji/tasks/4653/4653/repo -g /mnt/koji/repos/oc-fedora12-build/742/groups/comps.xml -r file:///tmp/koji/tasks/4653/4653/repo_742_premerge/ -r http://c4ebdaily.ltc.br.ibm.com/fedora/releases/12/Everything/i386/os/ -r http://c4ebdaily.ltc.br.ibm.com/fedora/updates/12/i386/ error: db4 error(12) from dbenv->open: Cannot allocate memory error: db4 error(12) from dbenv->close: Cannot allocate memory error: cannot open Packages index using db3 - Cannot allocate memory (12) error: cannot open Packages database in /var/lib/rpm Traceback (most recent call last): File "/usr/libexec/kojid/mergerepos", line 241, in <module> main(sys.argv[1:]) File "/usr/libexec/kojid/mergerepos", line 232, in main merge = RepoMerge(opts.repos, opts.arches, opts.groupfile, blocked, opts.outputdir) File "/usr/libexec/kojid/mergerepos", line 106, in __init__ self.yumbase.conf.cachedir = tempfile.mkdtemp() File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 652, in <lambda> conf = property(fget=lambda self: self._getConfig(), File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 239, in _getConfig self._conf = config.readMainConfig(startupconf) File "/usr/lib/python2.6/site-packages/yum/config.py", line 794, in readMainConfig yumvars['releasever'] = _getsysver(startupconf.installroot, startupconf.distroverpkg) File "/usr/lib/python2.6/site-packages/yum/config.py", line 867, in _getsysver idx = ts.dbMatch('provides', distroverpkg) TypeError: rpmdb open failed Exception AttributeError: "'YumBase' object has no attribute 'preconf'" in <bound method RepoMerge.__del__ of <__main__.RepoMerge object at 0x1b9d990>> ignored Exception AttributeError: "'YumBase' object has no attribute 'preconf'" in <bound method YumBase.__del__ of <yum.YumBase object at 0x1bb03d0>> ignored Regards Rodrigo Trujillo

1 0

Weird problem building zsh in local mock but not in koji
by Jason L Tibbitts III 24 Nov '09

24 Nov '09

I'm having a problem building the current zsh srpm (zsh-4.3.10-4.fc13.src.rpm) on my local builder, which runs F11-x86_64 and has mock-0.9.18-1.fc11.noarch. On IRC, a user reported the same problem, only his builder runs CentOS 5.4 and has mock-0.9.14-2.el5.noarch. Surprisingly, the same srpm will build fine in koji. I'm not sure how to describe the hang in enough detail without having to understand the zsh test framework. The bottom line is simply that one of the tests just hangs. It's doing some testing of the read builtin; I believe it's one of these two stanzas which hangs, although output buffering may make it difficult to be sure: read -d: <<<foo:bar print $REPLY 0:read up to delimiter >foo print foo:bar|IFS=: read -A print $reply 0:use different, IFS separator to array >foo bar The last thing in the build log is "Running test: read up to delimiter". ps just shows: tibbs 9322 0.0 0.0 114684 1916 pts/3 TN 12:39 00:00:00 ../Src/zsh +Z -f ./ztst.zsh ./B04read.ztst wchan is signal_stop. The process doesn't seem to be consuming any CPU, but if I strace it, I get an endless stream of ioctl(11, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon echo...}) = ? ERESTARTSYS (To be restarted) --- SIGTTOU (Stopped (tty output)) @ 0 (0) --- --- SIGTTOU (Stopped (tty output)) @ 0 (0) --- In koji there doesn't seem to be any delay at all running this test. I'm stumped. - J<

2 3

how to cancel (stop) the build task which has strange state
by peng chen 24 Nov '09

24 Nov '09

hello, fedora-buildsys-list: I encounter with several strange build tasks, which build state is building,but task state is failed. resultly, these build tasks are always in the building state. I run command "koji cancel " ,but failed to cancel it ,it's still there(my koji website). So, how could I cancel (stop ) these strange build tasks. In addition, during these package building, the koji server and building host had poweroffed. Thanks!

2 1

About priority on tag-inheritance
by peng chen 23 Nov '09

23 Nov '09

I wonder how the priority on tag-inheritance works. whether the priority number which is large has priority, or not? In other words, the larger the priority number is ,the priorer . is it like this?

3 2

mock-0.9.19 on CentOS5/RHEL5
by Florian La Roche 22 Nov '09

22 Nov '09

Hello, if you want to run the newest version of mock (0.9.19) with RHEL5/CentOS5, you can use a backported version from: http://www.jur-linux.org/rpms/el-updates/5/SRPMS/mock-0.9.19-1.el5.src.rpm http://www.jur-linux.org/rpms/el-updates/5/i386/mock-0.9.19-1.el5.noarch.rpm regards, Florian La Roche

4 5

How the pkglist of the repo associated with build tag is generated
by peng chen 20 Nov '09

20 Nov '09

for example,I have a target dist-test, it's detailed info as follow: Name Buildroot Destination ---------------------------------------------------------------------- dist-test dist-test-build dist-test I use command "koji list-tagged dist-test",and found the package in the list of dist-test,but when generating the repo associated with the build tag 'dist-test-build',the package doesn't exist in the file 'pkglist'.This results in Missing Dependency Error or Init mock buildroot Error. I reslove the problem this way that tag the missing package with command "koji call tagBuildBypass dist-test-build <the missing package n-v-r>" ,and then regen-repo,It's OK! So, I wonder why and how the content of file 'pkglist' is written? Thanks, sincerely!

2 1

Intermittent errors creating mock root cache tarball
by Paul Howarth 19 Nov '09

19 Nov '09

I have a buildsystem that targets a number of different distribution releases, and so I get to rebuild a root cache quite often. Quite frequently, the creation of the root cache tarball fails and causes the package build that triggered the root cache creation to fail. However, simply repeating the build invariably succeeds, and mock uses the supposedly failed cache tarball from the previous build without problems. I've not looked at this in detail because the workaround has been so easy but yesterday I decided to take a look at it. I think there are two issues. Firstly, the cause of the tarball creation failure. Looking at the root log, it appeared to be a change in one of the files whilst it was being archived by tar. DEBUG util.py, Line: 234: tar: ./usr/lib/locale/locale-archive: file changed as we read it The same problem with the same file was menioned in a report dating back two years on fedora-devel-list: http://www.redhat.com/archives/fedora-devel-list/2007-November/msg02599.html More googling revealed a possible cause of the problem: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg190963.html So I tried forcing a "sync" before creating the tarball and lo and behold, the problem went away. I've created at least 20 root caches since making this change and all worked fine, which I'm very confident wouldn't have been the case without the "sync". So here's the change I made: --- /usr/lib/python2.6/site-packages/mock/plugins/root_cache.py.orig 2009-09-02 19:08:54.000000000 +0100 +++ /usr/lib/python2.6/site-packages/mock/plugins/root_cache.py 2009-11-18 15:20:04.353035160 +0000 @@ -110,6 +110,7 @@ # never rebuild cache unless it was a clean build. if self.rootObj.chrootWasCleaned: self.state("creating cache") + mock.util.do(["sync"], shell=False) mock.util.do( ["tar"] + self.compressArgs + ["-cf", self.rootCacheFile, "-C", self.rootObj.makeChrootPath(), "."], The second problem is I think that if the "tar" process to create the tarball fails (and hence causes the resulting build to fail), the cache should be invalidated so that the next build doesn't use that presumably-broken tarball. As it happens, a faulty copy of /usr/lib/locale/locale-archive doesn't seem to cause any problems during my builds but that may just be my good fortune. Cheers, Paul.

1 0

Re: Postgresql Database Error
by peng chen 18 Nov '09

18 Nov '09

2009/11/19 <fedora-buildsys-list-request(a)redhat.com> > Send Fedora-buildsys-list mailing list submissions to > fedora-buildsys-list(a)redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > or, via email, send a message with subject or body 'help' to > fedora-buildsys-list-request(a)redhat.com > > You can reach the person managing the list at > fedora-buildsys-list-owner(a)redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Fedora-buildsys-list digest..." > > > Today's Topics: > > 1. Postgresql Database Error (peng chen) > 2. Re: Postgresql Database Error (Mike Bonnet) > 3. Re: Postgresql Database Error (Mike McLean) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 18 Nov 2009 15:15:46 +0800 > From: peng chen <peng.chen22(a)gmail.com> > Subject: Postgresql Database Error > To: fedora-buildsys-list(a)redhat.com > Message-ID: > <7e200e7f0911172315q4b2fc425p8575bdd7e2b74765(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > hello, fedora-buildsys-list: > > when I requset a build task for pakcage "anaconda" to koji, > one errie error come out. > It detailed as follow: > pg.DatabaseError: error ' ERROR: new row for relation "task" violates > check constraint "task_weight_check" ' > in ' UPDATE task SET weight=-0.9838856091396 WHERE id = 16296 ' > I'm sure that the source rpm of anaconda is OK,because I succed to build > it in local mock environment. and > the repo is the same as the koji build server. > hope you do me a favor sincerely! > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > https://www.redhat.com/archives/fedora-buildsys-list/attachments/20091118/b… > > ------------------------------ > > Message: 2 > Date: Wed, 18 Nov 2009 08:51:54 -0500 > From: Mike Bonnet <mikeb(a)redhat.com> > Subject: Re: Postgresql Database Error > To: fedora-buildsys-list(a)redhat.com > Message-ID: <4B03FBFA.2000001(a)redhat.com> > Content-Type: text/plain; charset=UTF-8 > > On 11/18/2009 02:15 AM, peng chen wrote: > > hello, fedora-buildsys-list: > > > > when I requset a build task for pakcage "anaconda" to koji, > > one errie error come out. > > It detailed as follow: > > pg.DatabaseError: error ' ERROR: new row for relation "task" violates > > check constraint "task_weight_check" ' > > in ' UPDATE task SET weight=-0.9838856091396 WHERE id = 16296 ' > > I'm sure that the source rpm of anaconda is OK,because I succed to > build > > it in local mock environment. and > > the repo is the same as the koji build server. > > hope you do me a favor sincerely! > > Does one of the builds have a completion_time earlier than its > create_event time? Koji uses the build duration to dynamically > calculate the weight of the task. It should probably be checking for a > negative result, but it doesn't. > > > > ------------------------------ > > Message: 3 > Date: Wed, 18 Nov 2009 08:56:59 -0500 > From: Mike McLean <mikem(a)redhat.com> > Subject: Re: Postgresql Database Error > To: fedora-buildsys-list(a)redhat.com > Message-ID: <4B03FD2B.5040909(a)redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 11/18/2009 02:15 AM, peng chen wrote: > > hello, fedora-buildsys-list: > > > > when I requset a build task for pakcage "anaconda" to koji, > > one errie error come out. > > It detailed as follow: > > pg.DatabaseError: error ' ERROR: new row for relation "task" > violates > > check constraint "task_weight_check" ' > > in ' UPDATE task SET weight=-0.9838856091396 WHERE id = 16296 ' > > I'm sure that the source rpm of anaconda is OK,because I succed to > build > > it in local mock environment. and > > the repo is the same as the koji build server. > > hope you do me a favor sincerely! > > The system time on your hub must have been set back during an anaconda > build and there must be sufficiently few anaconda builds for this to > cause getAverageBuildDuration('anaconda') to return a negative number. > > We should of course fix this, but you should also avoid rolling back the > time on your koji hosts, especially the hub and db hosts. > > In the meantime, this patch should help > --- a/builder/kojid > +++ b/builder/kojid > @@ -2033,6 +2033,9 @@ class BuildArchTask(BaseTaskHandler): > avg = session.getAverageBuildDuration(name) > if not avg: > return > + if avg < 0: > + self.logger.warn("Negative average build duration for %s: > %s", name, avg) > + return > # increase the task weight by 0.75 for every hour of build > duration > adj = (avg / 4800.0) > # cap the adjustment at +4.5 > > > > ------------------------------ > As Mike Bonnet said in message 2, one of anaconda builds had a > completion_time earlier than creation_time, so I find the one and remember > the build ID, then update the table "build" to make the completion_time > later than creation_time. > Now the problem was solved. Thanks again! > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > End of Fedora-buildsys-list Digest, Vol 57, Issue 5 > *************************************************** >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys November 2009