libgsm does not build as timestamped filenames change

[andreas@…]

building libgsmd-0.1+svnnow in bitbake does not work and exits during
installation with the following message:

| NOTE: make
DESTDIR=/home/moko/build/tmp/work/armv4t-linux/libgsmd-0.1+svnnow-r0_0_200708150003/image
install
| make: * No rule to make target `install'. Stop.
| FATAL: oe_runmake failed

The problem seems to be a bitbake problem as the timestamped filename does
change between the different macro calls:

NOTE: package libgsmd-0.1+svnnow: started
NOTE: package libgsmd-0.1+svnnow-r0_0_200708150002: task do_fetch: started
NOTE: Update ​svn://svn.openmoko.org/trunk/src/target;module=gsm;proto=http
At revision 2702.

Here the time is 00:02

NOTE: package libgsmd-0.1+svnnow: started
NOTE: package libgsmd-0.1+svnnow-r0_0_200708150003: task do_install: started

Install is called at 00:03 resulting in a different timestamped filename. The
directory in question is empty explaining why the install target cannot be found
as no Makefile is present.

Resetting the time at the appropriate time in a second window via date -s does
make the build complete.

[andreas@…]

Buildlog showing the problem

[stefan@…]

Do you use the old svn overlay or OE.dev directly?

Which bitbake version?

svn overlay needs 1.6.6
OE.dev needs 1.8.6

I run once into such a problem with the wrong bitbake version in regard to the
meta data. Let me know if it works with the right combination.

[andreas@…]

bitbake was 1.8.6

[andreas@…]

The build was done according to
​http://wiki.openmoko.org/wiki/Building_OpenMoko_from_scratch

[stefan@…]

Do you still have this problem?

Please try it again with using OE.dev directly. The new MokoMakefile? should take
care of this. ​http://wiki.openmoko.org/wiki/MokoMakefile

Of course you can also use bitbake and the oe metadata directly. We need some
time to update all the instructions in the wiki

[mickey@…]

Thanks for reporting. This is a known bug in BitBake?.

The best way to workaround is to just bitbake -c rebuild <the offending package>.

[mickey@…]

closing here, since this is an OE problem.