php.spec -> "configure" needs to be removed before "buildconf" is called?!
by Tim Richert
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
14 years, 6 months
everytime serveral packages built, then the package build tasks left alawys open or free
by peng chen
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!
14 years, 6 months
Mergerepos command error: Cannot allocate memory/ RPMDB open failed
by rotru@br.ibm.com
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
14 years, 6 months
Weird problem building zsh in local mock but not in koji
by Jason L Tibbitts III
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<
14 years, 6 months
how to cancel (stop) the build task which has strange state
by peng chen
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!
14 years, 6 months
About priority on tag-inheritance
by peng chen
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?
14 years, 6 months
How the pkglist of the repo associated with build tag is generated
by peng chen
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!
14 years, 6 months
Intermittent errors creating mock root cache tarball
by Paul Howarth
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.
14 years, 6 months
Re: Postgresql Database Error
by peng chen
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...
>
> ------------------------------
>
> 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
> ***************************************************
>
14 years, 6 months