configure error: Unknown location specification /usr/include/python2.6

Good: you are attempting a build slave.

Yes: the build master is currently targeting a
single platform: a RHEL6 clone with python-2.6.

One quick fix would be to remove this build option in devtool.conf
    %harwich
    ...
        --with-pythonembed=/usr/lib:/usr/include/python2.6 \
    ...
but there is almost certainly other options that won't be right.

The devtool.conf stanza that is appropriate for Mandriva is "cooker"
    ./devtool cooker

I will adjust the master.cfg on harwich to use "cooker" instead of "harwich"
until I get a chance to tie the build config in devtool.conf to specific
build slaves.

The master.cfg now invokes
    .devtool cooker
I will add the table to associate a build config with each build slave
later today.

The ROSA2012-nightly waterfall here
      http://harwich.jbj.org:8010/builders/ROSA2012-nightly/builds/26/steps/compile_2/logs/stdio
is now running ".devtool cooker" successfully.

The compile failure indicates that
   /usr/include/db52/db.h
isn't being included by rpmdb/dbconfig.c.

The gcc invocation has the necessary -I/usr/include/db52 line.

Examining the devtool output:

1) db52-utils isn't installed (%{_bindir} should have been an absolute path if present)
checking for db52_archive... %{_bindir}/db52_archive
checking for db52_checkpoint... %{_bindir}/db52_checkpoint
checking for db52_deadlock... %{_bindir}/db52_deadlock
checking for db52_dump... %{_bindir}/db52_dump
checking for db52_hotbackup... %{_bindir}/db52_hotbackup
checking for db52_load... %{_bindir}/db52_load
checking for db52_log_verify... %{_bindir}/db52_log_verify
checking for db52_printlog... %{_bindir}/db52_printlog
checking for db52_recover... %{_bindir}/db52_recover
checking for db52_replicate... %{_bindir}/db52_replicate
checking for db52_stat... %{_bindir}/db52sql
checking for db52_stat... %{_bindir}/db52_sql_codegen
checking for db52_stat... %{_bindir}/db52_stat
checking for db52_stat... %{_bindir}/db52_tuner
checking for db52_upgrade... %{_bindir}/db52_upgrade
checking for db52_verify... %{_bindir}/db52_verify

2) And you appear not to have db52-devel installed (or at least configure.ac cannot find)

++ executing success action
++ mapping --with-db=yes to --with-db="external"
++ searching location: external
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for db_create in -ldb-5.2... no
checking whether to build with Berkeley-DB library... no

So the root cause of the build failure (confirm by examining config.h) is that
you are attempting a build without Berkeley DB.

(aside)
The @rpm5.org project decided that they wished maximal
    Have it your own way!
build time configuration. So it is (or at least was) entirely possible to build RPM
   without any database support
   without any compression
RPM built without a database or compression is utterly useless of course.

The S6-nightly build is failing because the "harwich" stanza attempts
    --with-beecrypt=internal
but the (hard-wired) "./devtool cooker" in the buildbot master is
attempting
    --with-beecrypt=external
and REHL6 doesn't ship BeeCrypt because Red Hat is interested in
The One True Crypto package: NSS.

I will resurrect the S6-nightly waterfall per comment #2 as quickly as I get a chance
to merge in a better master/master.cfg stanza permitting per-slave build options.

Getting a ROSA2012-nightly build slave functional is more important atm.

Replying to comment #4

Jbj, EPEL6 contain beecrypt http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/beecrypt.html

Thank you!

Still: EPEL6 doesn't contain @rpm5.org code and I can hardly "trust"
linkage against hostile sources from projects that (for me and
mostly the @rpm5.org project) are non-participatory and "hostile".

I prefer
    --with-beecrypt=internal
for building @rpm5.org (nothing else links BeeCrypt because of
Red Hat removing in RHEL).

And I still prefer BeeCrypt as the highest performing crypto
framework I have measured. The ordering for performance
was
    BeeCrypt
    NSS
    opessl
and BeeCrypt was ~10% faster than NSS at the time.

The current state of RPM+crypto performance should likely be re-measured using
    rpm -Va --use-crypto=XX --stats
and published.

And -- if interested -- run the same command under call grind
to get a more objective benchmark which will also identify
other compute intensive bottlenecks.

And just for pedantic preciseness re crypto benchmarking:
     RPM always uses BeeCrypt for digests, the --usecrypto option is purely RSA/DSA related.

What that means is that to get a more accurate benchmark (as I performed
several years ago) you will need --nofiles
     rpm -Va --nofiles --use-crypto=XX --stats

Claims like "10% faster" are meaningless unless the benchmark comparison
basis is also stated pedantically precisely.

And a ROSA2012/i586 waterfall starts to flow at
    http://harwich.jbj.org:8010
using the "./devtool cooker" stanza.

I have sent Denis Silakov copious details of what was needed.

That "fixes" this bug, release will be in rpm-5.4.5 early March