3225 2012-10-03 20:59:15 +0000 linux-yocto SRCPV is changed after every MACHINE switch 2013-01-03 12:57:30 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel 1.3 x86 Multiple RESOLVED FIXED Medium normal 1.4 3071 1 Martin.Jansa constantinx.musca bruce.ashfield tom.zanussi --- --- --- oldest_to_newest 26179 0 Martin.Jansa 2012-10-03 20:59:15 +0000 Different machines are using different SRCREV_machine (because of potentionaly diferent branch) and LOCALCOUNT in SRCPV is increased after every MACHINE switch. Because they share the same key in persistent db: > > sqlite> select * from BB_URI_LOCALCOUNT where key like '%linux-yocto-3.4%'; > > git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_rev|84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d > > git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_count|16 > > git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_rev|463299bc2e533e1bd38b0053ae7b210980f269c3 > > git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_count|9 > > git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_rev|19f7e43b54aef08d58135ed2a897d77b624b320a > > git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_count|7 > > git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_rev|9032b1e9daf5b4396f939981c3be95f67802d18c > > git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_count|10 > > git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_rev|463299bc2e533e1bd38b0053ae7b210980f269c3 > > git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_count|8 More details here: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029413.html One possible solution is to drop machine from SRCREV_FORMAT and bump PR with every SRCREV_machine change http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030227.html but RP says it won't work with current fetcher. 27667 1 richard.purdie 2012-11-25 21:49:36 +0000 If we fix 3371, this problem should go away... 28516 2 constantinx.musca 2013-01-03 12:57:30 +0000 Since we fixed 3071, we don't have this problem anymore. Cheers, Constantin