[Sisuite-devel] Building SystemImager on PS3 -- dtc needed?

[Bernard Li]

DongInn was trying to build SystemImager on PS3 with my latest SRPM
and got the following errors:

strip -s -R .comment vmlinux -o vmlinux.strip
WRAP arch/powerpc/boot/zImage.ps3
/usr/src/yellowdog/BUILD/systemimager-4.0.1.svn4352.kexecfix+rsync3pre6.bli/src/linux-2.6.23-20071023/arch/powerpc/boot/wrapper:
line 113: dtc: command not found
make[2]: *** [arch/powerpc/boot/zImage.ps3] Error 1
make[1]: *** [zImage] Error 2
make[1]: Leaving directory
`/usr/src/yellowdog/BUILD/systemimager-4.0.1.svn4352.kexecfix+rsync3pre6.bli/src/linux-2.6.23-20071023'
make: *** [/usr/src/yellowdog/BUILD/systemimager-4.0.1.svn4352.kexecfix+rsync3pre6.bli/src/linux-2.6.23-20071023/vmlinux.strip]
Error 2
error: Bad exit status from /var/tmp/rpm-tmp.45059 (%build)

dtc is missing -- should I add this dependency to
systemimager-ppc64-ps3boot-standard?

Andrea -- DongInn mentioned that when he rebuilt your 4.0.1 SRPM, he
didn't encounter this problem, do you know anything about this?

Thanks,

Bernard

[Andrea Righi]

Post by Bernard Li
DongInn was trying to build SystemImager on PS3 with my latest SRPM
strip -s -R .comment vmlinux -o vmlinux.strip
WRAP arch/powerpc/boot/zImage.ps3
line 113: dtc: command not found
make[2]: *** [arch/powerpc/boot/zImage.ps3] Error 1
make[1]: *** [zImage] Error 2
make[1]: Leaving directory
`/usr/src/yellowdog/BUILD/systemimager-4.0.1.svn4352.kexecfix+rsync3pre6.bli/src/linux-2.6.23-20071023'
make: *** [/usr/src/yellowdog/BUILD/systemimager-4.0.1.svn4352.kexecfix+rsync3pre6.bli/src/linux-2.6.23-20071023/vmlinux.strip]
Error 2
error: Bad exit status from /var/tmp/rpm-tmp.45059 (%build)
dtc is missing -- should I add this dependency to
systemimager-ppc64-ps3boot-standard?
Andrea -- DongInn mentioned that when he rebuilt your 4.0.1 SRPM, he
didn't encounter this problem, do you know anything about this?

The latest trunk uses a 2.6.23 kernel that needs the dtc compiler, see:
http://www.kernel.org/pub/linux/kernel/people/geoff/cell/CELL-Linux-CL_20071023-ADDON/doc/LinuxKernelOverview.html

In Ubuntu it should be sufficient to add a build-dependency on
device-tree-compiler package:
http://packages.ubuntu.com/feisty/devel/device-tree-compiler

I don't know if this is shipped with RH distributions too, otherwise you should
download and build it from source. In any case we should add a build-dependency
also for RPMs and only for PS3 arch.

Anyway, the latest trunk is quite unstable/untested, I mean, a lot of core
packages have been updated, in particular kernel and busybox. FYI the next
stable release will be based on the 4.0.x branch.

-Andrea

[Bernard Li]

Post by Andrea Righi
I don't know if this is shipped with RH distributions too, otherwise you should
download and build it from source. In any case we should add a build-dependency
also for RPMs and only for PS3 arch.

dtc comes with Fedora 8 -- I think we should just add the dependency,
the worst case is that the user needs to download the SRPM, rebuild
and install (which is what I did).

Post by Andrea Righi
Anyway, the latest trunk is quite unstable/untested, I mean, a lot of core
packages have been updated, in particular kernel and busybox. FYI the next
stable release will be based on the 4.0.x branch.

In this case we should probably increment the VERSION file of trunk --
it is currently set at 4.0.1 which is the same as the 4.0.x branch.

Thanks,

Bernard

[Andrea Righi]

Post by Bernard Li

Post by Andrea Righi
I don't know if this is shipped with RH distributions too, otherwise you should
download and build it from source. In any case we should add a build-dependency
also for RPMs and only for PS3 arch.

dtc comes with Fedora 8 -- I think we should just add the dependency,
the worst case is that the user needs to download the SRPM, rebuild
and install (which is what I did).

Yes, the only drawback is that it's only needed to build PS3 packages, and it
wouldn't be good to introduce a new dependency for all the other architectures,
but probably this is better than failing the build process for a missing
dependency.

Post by Bernard Li

Post by Andrea Righi
Anyway, the latest trunk is quite unstable/untested, I mean, a lot of core
packages have been updated, in particular kernel and busybox. FYI the next
stable release will be based on the 4.0.x branch.

In this case we should probably increment the VERSION file of trunk --
it is currently set at 4.0.1 which is the same as the 4.0.x branch.

Done.

-Andrea

[Bernard Li]

Post by Andrea Righi
Yes, the only drawback is that it's only needed to build PS3 packages, and it
wouldn't be good to introduce a new dependency for all the other architectures,
but probably this is better than failing the build process for a missing
dependency.

At least for RPM, I only added the dependency if we're on PS3, see:

http://www.systemimager.org:8000/trac.systemimager.org/changeset/4355

Didn't really test it, but should work :-)

BTW, questions about this changeset:

http://svn.systemimager.org:8000/trac.systemimager.org/changeset/4357

Is the VERSION file really needed? Perhaps we should modify simply
the configure.ac file for version increments (less files to modify =
less prone to errors).

Should we really check in the configure script? It might be better to
have the developer simply run bootstrap (or whatever tool to generate
the configure script).

My $0.02.

Cheers,

Bernard

[Andrea Righi]

Post by Bernard Li

Post by Andrea Righi
Yes, the only drawback is that it's only needed to build PS3 packages, and it
wouldn't be good to introduce a new dependency for all the other architectures,
but probably this is better than failing the build process for a missing
dependency.

http://www.systemimager.org:8000/trac.systemimager.org/changeset/4355
Didn't really test it, but should work :-)

OK, I'll see if it's possible to do something similar with deb.

Post by Bernard Li
http://svn.systemimager.org:8000/trac.systemimager.org/changeset/4357
Is the VERSION file really needed? Perhaps we should modify simply
the configure.ac file for version increments (less files to modify =
less prone to errors).
Should we really check in the configure script? It might be better to
have the developer simply run bootstrap (or whatever tool to generate
the configure script).

Sounds good to have a single file. Anyway, the version string in the configure
is pretty useless: it appears only in the configure help and in some comments,
so I wouldn't consider it a critical issue.

IMHO the best solution is to add a simple code in autoconf/bootstrap to
automatically re-generate both the VERSION and the configure files, depening on
the version string defined in autoconf/configure.ac. In this way we could simply
remove VERSION and configure from the svn repository, since they'll be
re-generated automatically as an initial build step.

-Andrea