Re: S variable for svn fetcher Was: State of OE world - 2020-02-18

[Tom Rini <trini@konsulko.com>]

On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
> On Wed, Feb 19, 2020 at 09:29:58AM -0800, Khem Raj wrote:
> > http://www.openembedded.org/wiki/Bitbake_World_Status
> > 
> > == Failed tasks /media/ra_build_share/buildlogs/oe/world/dunfell/2020-02-18 ==
> > 
> > INFO: jenkins-job.sh-1.8.46 Complete log available at
> > /media/ra_build_share/buildlogs/oe/world/dunfell//media/ra_build_share/buildlogs/oe/world/dunfell/log.report.20200219_150007.log
> > 
> > === common (0) ===
> > 
> > === common-x86 (0) ===
> > 
> > === qemuarm (0) ===
> > 
> > === qemuarm64 (0) ===
> > 
> > === qemux86 (0) ===
> > 
> > === qemux86_64 (0) ===
> 
> Looks great! Thanks
> 
> I was running some world builds recently as well and was surprised that
> there are a few failing recipes in meta-oe:
>   s3c24xx-gpio
>   s3c64xx-gpio
>   wmiconfig
>   usbpath
> which are all using svn fetcher.
> 
> Any idea why these aren't shown in our build? I was able to reproduce
> this on thud as well as latest master build:
> 
>   /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/usbpath/usbpath_svn.bb:do_patch
>   /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:do_compile
>   /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:do_compile
>   /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:do_populate_lic
>   /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:do_populate_lic
>   /OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/wmiconfig/wmiconfig_svn.bb:do_patch
> 
> they have all the same root cause and that is that the
> S variable points to directory where the sources used to be, but now
> they are checked out somewhere else, e.g. s3c24xx-gpio:
> 
> LIC_FILES_CHKSUM = "file://gpio.c;endline=12;md5=cfb91c686857b2e60852b4925d90a3e1"
> 
> SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=gpio;protocol=http"
> 
> S = "${WORKDIR}/gpio"
> 
> And now S looks like this:
> $ ls /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/s3c24xx-gpio/1.0+svnr4949-r2/gpio/
> branches  trunk
> 
> While before I believe it was checking out just this directory (as ${WORKDIR}/gpio):
> $ ls /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/s3c24xx-gpio/1.0+svnr4949-r2/gpio/trunk/src/target/gpio/
> gpio.c  gpio-glamo.c  gpio-s3c6410.c  Makefile  README
> 
> Anyone still actively using svn fetcher for something?
> 
> I'll check with even older bitbake to see when it changed, but it's
> still surprising that you wouldn't be seeing it with latest bitbake
> in world builds.

Chiming in as this caught my eye.  I've run in to this perhaps with
'warrior' as well recently for a customer.  I assumed it was just that
it had been so long since I had used SVN I had just mis-remembered how
S needed to be set.  I also as a tangent noticed that AUTOREV for svn
seems broken as it doesn't ensure we have subversion-native in the
sysroot ('svn command not found' is the relevant part of the failure).

-- 
Tom