State of OE world - 2020-02-18

State of OE world - 2020-02-18

[Khem Raj]

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) ===

=== Number of failed tasks (0) ===
{| class=wikitable
|-
|| qemuarm || 0 ||
/media/ra_build_share/buildlogs/oe/world/dunfell//media/ra_build_share/buildlogs/oe/world/dunfell/log.world.qemuarm.20200218_155946.log/
||
|-
|| qemuarm64 || 0 ||
/media/ra_build_share/buildlogs/oe/world/dunfell//media/ra_build_share/buildlogs/oe/world/dunfell/log.world.qemuarm64.20200218_235936.log/
||
|-
|| qemux86 || 0 ||
/media/ra_build_share/buildlogs/oe/world/dunfell//media/ra_build_share/buildlogs/oe/world/dunfell/log.world.qemux86.20200218_235938.log/
||
|-
|| qemux86_64 || 0 ||
/media/ra_build_share/buildlogs/oe/world/dunfell//media/ra_build_share/buildlogs/oe/world/dunfell/log.world.qemux86-64.20200218_235937.log/
||
|}

=== PNBLACKLISTs (22) ===


sources/meta-openembedded:
    * meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb:PNBLACKLIST[netkit-rusers]
= "Fails to build rup.c:51:10: fatal error: rstat.h: No such file or
directory"
    * meta-networking/recipes-support/drbd/drbd_9.0.19-1.bb:PNBLACKLIST[drbd]
= "Kernel module Needs forward porting to kernel 5.2+"
    * meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb:PNBLACKLIST[lowpan-tools]
= "WARNING these tools are deprecated! Use wpan-tools instead"
    * meta-oe/recipes-devtools/dnf-plugin-tui/dnf-plugin-tui_git.bb:PNBLACKLIST[dnf-plugin-tui]
?= "${@bb.utils.contains('PACKAGE_CLASSES', 'package_rpm', '', 'does
not build correctly without package_rpm in PACKAGE_CLASSES', d)}"
    * meta-oe/recipes-devtools/nanopb/nanopb_0.4.0.bb:PNBLACKLIST[nanopb]
= "Needs forward porting to use python3"
    * meta-oe/recipes-extended/socketcan/can-isotp_git.bb:PNBLACKLIST[can-isotp]
= "Kernel module Needs forward porting to kernel 5.2+"
    * meta-oe/recipes-extended/sysdig/sysdig_git.bb:PNBLACKLIST[sysdig]
= "configure: error: in
'TOPDIR/build/tmpfs/work/core2-64-yoe-linux/sysdig/0.26.4-r0/build/c-ares-prefix/src/c-ares'"
    * meta-oe/recipes-graphics/dnfdragora/dnfdragora_git.bb:PNBLACKLIST[dnfdragora]
?= "${@bb.utils.contains('PACKAGE_CLASSES', 'package_rpm', '', 'does
not build correctly without package_rpm in PACKAGE_CLASSES', d)}"
    * meta-oe/recipes-kernel/bpftool/bpftool.bb:PNBLACKLIST[bpftool] =
"Needs forward porting to kernel 5.2+"


sources/meta-qt5:
    * recipes-python/pyqt5/python-pyqt5_5.13.2.bb:PNBLACKLIST[python-pyqt5]
= "Sip fails in do_configure sip: QOpenGLFramebufferObject is
undefined"


sources/meta-yoe:
    * conf/distro/yoe.inc:PNBLACKLIST[build-appliance-image] = "tries
to include whole downloads directory in /home/builder/poky :/"
    * conf/distro/yoe.inc:PNBLACKLIST[smartrefrigerator] = "Needs
porting to QT > 5.6"
    * conf/distro/yoe.inc:PNBLACKLIST[qmlbrowser] = "Needs porting to QT > 5.6"
    * conf/distro/yoe.inc:PNBLACKLIST[minehunt] = "Needs porting to QT > 5.6"
    * conf/distro/yoe.inc:PNBLACKLIST[homeautomation] = "Needs porting
to QT > 5.6"
    * conf/distro/yoe.inc:PNBLACKLIST[samegame] = "Needs porting to QT > 5.6"
    * conf/distro/yoe.inc:PNBLACKLIST[applicationlauncher] = "Needs
porting to QT > 5.6"
    * conf/distro/yoe.inc:PNBLACKLIST[spacetouch] = "Needs porting to
libplanes 1.0"
    * conf/distro/yoe.inc:PNBLACKLIST[qtviewplanes] = "Needs porting
to libplanes 1.0"
    * conf/distro/yoe.inc:PNBLACKLIST[egt-thermostat] = "Needs porting
to egt 0.8.2+"


sources/openembedded-core:
    * meta/recipes-devtools/dnf/dnf_4.2.2.bb:PNBLACKLIST[dnf] ?=
"${@bb.utils.contains('PACKAGE_CLASSES', 'package_rpm', '', 'does not
build correctly without package_rpm in PACKAGE_CLASSES', d)}"
    * meta/recipes-devtools/libdnf/libdnf_0.28.1.bb:PNBLACKLIST[libdnf]
?= "${@bb.utils.contains('PACKAGE_CLASSES', 'package_rpm', '', 'does
not build correctly without package_rpm in PACKAGE_CLASSES', d)}"


conf/local.conf:
    * PNBLACKLIST[bigbuckbunny-1080p] = "big and doesn't really need
to be tested so much"
    * PNBLACKLIST[bigbuckbunny-480p] = "big and doesn't really need to
be tested so much"
    * PNBLACKLIST[bigbuckbunny-720p] = "big and doesn't really need to
be tested so much"
    * PNBLACKLIST[tearsofsteel-1080p] = "big and doesn't really need
to be tested so much"
    * PNBLACKLIST[build-appliance-image] = "tries to include whole
downloads directory in /home/builder/poky :/"

=== QA issues (0) ===
{| class=wikitable
!| Count ||Issue
|-
||0 ||already-stripped
|-
||0 ||build-deps
|-
||0 ||compile-host-path
|-
||0 ||file-rdeps
|-
||0 ||host-user-contaminated
|-
||0 ||installed-vs-shipped
|-
||0 ||invalid-pkgconfig
|-
||0 ||ldflags
|-
||0 ||libdir
|-
||0 ||pkgname
|-
||0 ||qa_pseudo
|-
||0 ||symlink-to-sysroot
|-
||0 ||textrel
|-
||0 ||unknown-configure-option
|-
||0 ||version-going-backwards
|}



=== Incorrect PACKAGE_ARCH or sstate signatures (0) ===

Complete log: /media/ra_build_share/buildlogs/oe/world/dunfell//media/ra_build_share/buildlogs/oe/world/dunfell/log.signatures.20200219_065929.log/

No issues detected


QA issues by type:
count: 0 issue: already-stripped


count: 0 issue: libdir


count: 0 issue: textrel


count: 0 issue: build-deps


count: 0 issue: file-rdeps


count: 0 issue: version-going-backwards


count: 0 issue: host-user-contaminated


count: 0 issue: installed-vs-shipped


count: 0 issue: unknown-configure-option


count: 0 issue: symlink-to-sysroot


count: 0 issue: invalid-pkgconfig


count: 0 issue: pkgname


count: 0 issue: ldflags


count: 0 issue: compile-host-path


count: 0 issue: qa_pseudo



This git log matches with the metadata as seen by qemuarm build.
In some cases qemux86 and qemux86-64 builds are built with slightly
different metadata, you can see the exact version near the top of each
log.world.qemu* files linked from the report
~/oe/world/yoe ~/oe/world/yoe

== Tested changes (not included in master yet) - bitbake ==
latest upstream commit:
5d98d8e3 cooker/siggen: Empty siggen cache during parsing
not included in master yet:
dc7d32ff runqueue: Possible tid handling optimisation
01ff1090 knotty: Make the bb.command.CommandExit event terminate bitbake
35cf83cd fetch2: Make fetcher_compare_revisions() work
0771b3a0 fetch2: Allow ${AUTOREV} to be used when BB_SRCREV_POLICY is "cache"
9c6eb977 data: Don't allow renameVar calls with equivalent keys
65419e33 cooker: Reset loghandler

== Tested changes (not included in master yet) - openembedded-core ==
latest upstream commit:
c9b5802bbe openssh: Upgrade 8.1p1 -> 8.2p1
not included in master yet:
13e1363cde oescripts.py: use unittest.SkipUnless for class skip
5414e256e7 base.bbclass: extend PACKAGECONFIG for conflict package configs
59e9c52807 glew/curl: specify exclusive package configs
a112eb667d HACK: signing: Add extra test debug
59328e8092 sstatesig: Log timestamps for hashequiv in reprodubile builds
7a9fa1683c rootfs-postcommands: Remove spaces before ; in -ROOTFS_..._COMMAND
1a4872c94e HACK: extra debug
e133b7f015 newlib: Move syscalls from newlib to libgloss
ad48167cd5 procps: upstream has switched to gitlab
9087ae6af1 qemux86: do not add vga=0 to kernel parameters
a7658b2564 qemux86: drop resolution setting via uvesafb
d9db0bb09d weston: add a basic runtime test
a69d8015d9 ptest-packagelists: mention ifupdown ptest in a comment
03fb91067f python3: resolve ncurses host contamination
b4b251a9a1 fix various, innocuous typos
beb5431370 systemd: upgrade v244.1 -> v244.3
250608b408 insane.bbclass: Correct typo inhert->inherit
688052a94b babeltrace: update to 1.5.8
0586fcdc04 webkitgtk: Fix errors when api-documentation is enabled
6b742380b7 p11-kit: Fix builds with systemd
94887b7f63 concurrencytest.py: add outSideTestaddSkip for subunit
8ea40e11c8 glibc-package.inc: fix multilib headers conflict
36ff08511b perl: Fix encode module reproducibility issues
cb75b6806b iproute2: add devlink support to iproute2
02df17f909 glib-2.0: add dependencies to fix ptest failures
e940c7f1c8 runit: Add runit and related recipes
a9096a5598 qemux86: Add identical qemux86copy variant for tests
8fd55d85b3 qemuppc64: Add a QEMU machine definition for ppc64
22668875c1 linux-yocto: Add powerpc64le support
2e476e3f40 report-error: Allow to upload reports automatically
ecd5f49df9 report-error.bbclass: replace angle brackets with < and >
6a7e548e87 libsolv: Enable rpm packageconfig by default only if rpm
O_P_M is enabled
799e34d485 dnf,libdnf: Ignore if PACKAGE_CLASSES does not have rpm

== Tested changes (not included in master yet) - meta-openembedded ==
latest upstream commit:
d459ead5c xfce4-whiskermenu-plugin: upgrade 2.3.5 -> 2.4.2
not included in master yet:
9f3e738cb mpv: Disable lua support for riscv
cbe0b4301 libgphoto2: remove executable permission bits of udev rule file
416c4f7d5 perl: Add libperlio-gzip-perl and libjson-perl
64441dc46 lcov: Add support for intermediate JSON format
7002e7dd3 lcov: Add missing missing RDEPEND and enable nativesdk
dec5ceaac python3-pyflakes: Add python3 version
71c233683 netplan: rdep on python3 version of pyflakes
b89254a8b rsyslog: Use python3 in ptests
7b0d354fb x265: Move into meta-multimedia
0bb390bbb gssdp: Upgrade to 1.2.2
7672f53cb gupnp: Upgrade to 1.2.2
385752703 gupnp-dlna: Rename patchdir to PN
a067634be rygel: Upgrade to 0.38.3
d474aab6a gupnp-tools: Upgrade to 0.10.0
eb50fb0ae gupnp-igd: Upgrade to 0.2.5
af2be2e96 gupnp-av: Upgrade to 0.12.11
c3a23760b drone: Add CI support
75591d24f sysdig: Upgrade to 0.26.4
2e3caaf9c fetchmail: upgrade 6.4.1 -> 6.4.2
074d8ec67 libnet-dns-perl: upgrade 1.21 -> 1.22
6db4dbf1c cifs-utils: upgrade 6.9 -> 6.10
2d909ef26 dleyna-core: Update to latest to support gupnp 1.2
8b5f4e5fc dleyna-server: Bump version to support 1.2 gupnp
6a9c2a271 graphviz: Depend on py3 at runtime
3115a33c9 pm-graph: Renamed from analyze-suspend
d000373e1 cfengine: Upgrade to 3.15
1ad1a99ff dleyna-renderer: Fix build with gupnp 1.2+
98f20ffec mariadb: Add pam_auth to server package.

== Tested changes (not included in master yet) - meta-qt5 ==
latest upstream commit:
2391474 Revert "qtwebkit: remove"
not included in master yet:
0bbd0eb qtwebengine: Link libatomic on x86/32bit
c8cd55b qtwebkit: build with python3
f18d594 qtbase: fix build with platform where FE macro are not defined
caf09cd Add PyQtChart.
b45a400 qtwebview: Skip if meta-python is not present

== Tested changes (not included in master yet) - meta-browser ==
latest upstream commit:
1697014 chromium: Fix patch fuzz
not included in master yet:
bc02d6d chromium: Fix build on 32bit arches with 64bit time_t
334855d chromium: Fix build with clang10/gcc10
~/oe/world/yoe

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

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]

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.

Cheers,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

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

[Tom Rini]

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

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

[Adrian Bunk]

On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
>...
> Any idea why these aren't shown in our build?
>...

What is your mirror configuration?

Default configuration downloads the tarball from [1].

> Cheers,

cu
Adrian

[1] http://downloads.yoctoproject.org/mirror/sources/

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

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

On Thu, Feb 20, 2020 at 05:16:20PM +0200, Adrian Bunk wrote:
> On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
> >...
> > Any idea why these aren't shown in our build?
> >...
> 
> What is your mirror configuration?
> 
> Default configuration downloads the tarball from [1].

Maybe I'm missing your point, but these aren't fetch issues.

Even when bitbake fetches the tarball (with the svn repo), svn fetcher
will still do the actual checkout to WORKDIR, so it will fail the same
when fetching from upstream repo with svn or when using tarball.

Cheers,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

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

[Khem Raj]

On Thu, Feb 20, 2020 at 6:48 AM Martin Jansa <martin.jansa@gmail.com> 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:
>

perhaps it might be due to the fact that yoe distro uses yocto and oe
source mirrors for tarballs

>   /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.
>
> Cheers,

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

[Adrian Bunk]

On Thu, Feb 20, 2020 at 04:37:58PM +0100, Martin Jansa wrote:
> On Thu, Feb 20, 2020 at 05:16:20PM +0200, Adrian Bunk wrote:
> > On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
> > >...
> > > Any idea why these aren't shown in our build?
> > >...
> > 
> > What is your mirror configuration?
> > 
> > Default configuration downloads the tarball from [1].
> 
> Maybe I'm missing your point, but these aren't fetch issues.
>...

MIRRORS = "" (and deleting the downloaded tar) is what I needed for 
getting a build failure.

> Cheers,

cu
Adrian

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

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

On Thu, Feb 20, 2020 at 06:11:59PM +0200, Adrian Bunk wrote:
> On Thu, Feb 20, 2020 at 04:37:58PM +0100, Martin Jansa wrote:
> > On Thu, Feb 20, 2020 at 05:16:20PM +0200, Adrian Bunk wrote:
> > > On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
> > > >...
> > > > Any idea why these aren't shown in our build?
> > > >...
> > > 
> > > What is your mirror configuration?
> > > 
> > > Default configuration downloads the tarball from [1].
> > 
> > Maybe I'm missing your point, but these aren't fetch issues.
> >...
> 
> MIRRORS = "" (and deleting the downloaded tar) is what I needed for 
> getting a build failure.

OK, I see now, sorry.

That explains why it's not shown in khem's builds and might be broken
well before thud already, the tarball created here today:

$ tar xvf ../downloads/gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
gpio/
gpio/trunk/
gpio/trunk/doc/
gpio/trunk/doc/hardware/
gpio/trunk/doc/hardware/GTA01Bv3/
gpio/trunk/doc/hardware/GTA01Bv3/gpio.txt
gpio/trunk/doc/hardware/GTA01Bv3/pmu-voltage.txt
...

while the corresponding tarball on mirror:
http://sources.openembedded.org/gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
$ tar xvf gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
gpio/
gpio/gpio-s3c6410.c
gpio/Makefile
gpio/gpio.c
gpio/gpio-glamo.c
gpio/README

Will check when it got broken before thud.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

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

[Khem Raj]

On Thu, Feb 20, 2020 at 7:38 AM Martin Jansa <martin.jansa@gmail.com> wrote:
>
> On Thu, Feb 20, 2020 at 05:16:20PM +0200, Adrian Bunk wrote:
> > On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
> > >...
> > > Any idea why these aren't shown in our build?
> > >...
> >
> > What is your mirror configuration?
> >
> > Default configuration downloads the tarball from [1].
>
> Maybe I'm missing your point, but these aren't fetch issues.
>
> Even when bitbake fetches the tarball (with the svn repo), svn fetcher
> will still do the actual checkout to WORKDIR, so it will fail the same
> when fetching from upstream repo with svn or when using tarball.
>

they could have been fetched long time ago, perhaps it changed in this
area after that
when fetching fresh repos, just guessing

> Cheers,

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

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3938 bytes --]

On Thu, Feb 20, 2020 at 05:23:12PM +0100, Martin Jansa wrote:
> On Thu, Feb 20, 2020 at 06:11:59PM +0200, Adrian Bunk wrote:
> > On Thu, Feb 20, 2020 at 04:37:58PM +0100, Martin Jansa wrote:
> > > On Thu, Feb 20, 2020 at 05:16:20PM +0200, Adrian Bunk wrote:
> > > > On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
> > > > >...
> > > > > Any idea why these aren't shown in our build?
> > > > >...
> > > > 
> > > > What is your mirror configuration?
> > > > 
> > > > Default configuration downloads the tarball from [1].
> > > 
> > > Maybe I'm missing your point, but these aren't fetch issues.
> > >...
> > 
> > MIRRORS = "" (and deleting the downloaded tar) is what I needed for 
> > getting a build failure.
> 
> OK, I see now, sorry.
> 
> That explains why it's not shown in khem's builds and might be broken
> well before thud already, the tarball created here today:
> 
> $ tar xvf ../downloads/gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
> gpio/
> gpio/trunk/
> gpio/trunk/doc/
> gpio/trunk/doc/hardware/
> gpio/trunk/doc/hardware/GTA01Bv3/
> gpio/trunk/doc/hardware/GTA01Bv3/gpio.txt
> gpio/trunk/doc/hardware/GTA01Bv3/pmu-voltage.txt
> ...
> 
> while the corresponding tarball on mirror:
> http://sources.openembedded.org/gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
> $ tar xvf gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
> gpio/
> gpio/gpio-s3c6410.c
> gpio/Makefile
> gpio/gpio.c
> gpio/gpio-glamo.c
> gpio/README
> 
> Will check when it got broken before thud.

It's still reproducible in pyro, so probably not caused by changes in OE.

There is one more recipe using svn in meta-multimedia which works fine:
meta-multimedia/recipes-dvb/oscam/oscam_svn.bb:SRC_URI = "svn://www.streamboard.tv/svn/oscam;module=trunk;protocol=http \

The rest are all from svn.openmoko.org:
meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=gpio;protocol=http"
meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=gpio;protocol=http"
meta-oe/recipes-support/samsung-soc-utils/sjf2410-linux-native_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/host/;module=sjf2410-linux;protocol=http \
meta-oe/recipes-support/usbpath/usbpath_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/host;module=usbpath;protocol=http \
meta-oe/recipes-support/wmiconfig/wmiconfig_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=AR6kSDK.build_sw.18;protocol=http \

And now this leads to do_fetch running:
svn --non-interactive --trust-server-cert co --no-auth-cache --ignore-externals -r 4949 http://svn.openmoko.org/trunk/src/target/gpio@4949 gpio
as before, but now it redirects to github:

Redirecting to URL 'https://github.com/openmoko/openmoko-svn':
A    gpio/branches
A    gpio/branches/oe
A    gpio/branches/oe/pre-20070305
A    gpio/branches/oe/pre-20070305/README
A    gpio/branches/oe/pre-20070305/classes
A    gpio/branches/oe/pre-20070305/classes/autotools.bbclass
A    gpio/branches/oe/pre-20070305/classes/base.bbclass
A    gpio/branches/oe/pre-20070305/classes/openmoko-base.bbclass
A    gpio/branches/oe/pre-20070305/classes/openmoko-panel-plugin.bbclass
..

and the svn bridge to github probably doesn't work exactly the same as the
native svn repo used to work, but I don't see it explicitly mentioned in:
https://help.github.com/en/github/importing-your-projects-to-github/support-for-subversion-clients

So to resolve this quickly I'm going to send SRC_URI updates for
these recipes to just use git fetcher from:
https://github.com/openmoko/openmoko-svn
directly. I don't think anyone is using these nowadays, so it's
also fine with me to just delete them all, which I'll do in
separate follow-up commit in case someone tries to resurrect them
later in own layer.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

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

[Khem Raj]

On 2/20/20 9:34 AM, Martin Jansa wrote:
> On Thu, Feb 20, 2020 at 05:23:12PM +0100, Martin Jansa wrote:
>> On Thu, Feb 20, 2020 at 06:11:59PM +0200, Adrian Bunk wrote:
>>> On Thu, Feb 20, 2020 at 04:37:58PM +0100, Martin Jansa wrote:
>>>> On Thu, Feb 20, 2020 at 05:16:20PM +0200, Adrian Bunk wrote:
>>>>> On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
>>>>>> ...
>>>>>> Any idea why these aren't shown in our build?
>>>>>> ...
>>>>>
>>>>> What is your mirror configuration?
>>>>>
>>>>> Default configuration downloads the tarball from [1].
>>>>
>>>> Maybe I'm missing your point, but these aren't fetch issues.
>>>> ...
>>>
>>> MIRRORS = "" (and deleting the downloaded tar) is what I needed for
>>> getting a build failure.
>>
>> OK, I see now, sorry.
>>
>> That explains why it's not shown in khem's builds and might be broken
>> well before thud already, the tarball created here today:
>>
>> $ tar xvf ../downloads/gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
>> gpio/
>> gpio/trunk/
>> gpio/trunk/doc/
>> gpio/trunk/doc/hardware/
>> gpio/trunk/doc/hardware/GTA01Bv3/
>> gpio/trunk/doc/hardware/GTA01Bv3/gpio.txt
>> gpio/trunk/doc/hardware/GTA01Bv3/pmu-voltage.txt
>> ...
>>
>> while the corresponding tarball on mirror:
>> http://sources.openembedded.org/gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
>> $ tar xvf gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
>> gpio/
>> gpio/gpio-s3c6410.c
>> gpio/Makefile
>> gpio/gpio.c
>> gpio/gpio-glamo.c
>> gpio/README
>>
>> Will check when it got broken before thud.
> 
> It's still reproducible in pyro, so probably not caused by changes in OE.
> 
> There is one more recipe using svn in meta-multimedia which works fine:
> meta-multimedia/recipes-dvb/oscam/oscam_svn.bb:SRC_URI = "svn://www.streamboard.tv/svn/oscam;module=trunk;protocol=http \
> 
> The rest are all from svn.openmoko.org:
> meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=gpio;protocol=http"
> meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=gpio;protocol=http"
> meta-oe/recipes-support/samsung-soc-utils/sjf2410-linux-native_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/host/;module=sjf2410-linux;protocol=http \
> meta-oe/recipes-support/usbpath/usbpath_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/host;module=usbpath;protocol=http \
> meta-oe/recipes-support/wmiconfig/wmiconfig_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=AR6kSDK.build_sw.18;protocol=http \
> 
> And now this leads to do_fetch running:
> svn --non-interactive --trust-server-cert co --no-auth-cache --ignore-externals -r 4949 http://svn.openmoko.org/trunk/src/target/gpio@4949 gpio
> as before, but now it redirects to github:
> 
> Redirecting to URL 'https://github.com/openmoko/openmoko-svn':
> A    gpio/branches
> A    gpio/branches/oe
> A    gpio/branches/oe/pre-20070305
> A    gpio/branches/oe/pre-20070305/README
> A    gpio/branches/oe/pre-20070305/classes
> A    gpio/branches/oe/pre-20070305/classes/autotools.bbclass
> A    gpio/branches/oe/pre-20070305/classes/base.bbclass
> A    gpio/branches/oe/pre-20070305/classes/openmoko-base.bbclass
> A    gpio/branches/oe/pre-20070305/classes/openmoko-panel-plugin.bbclass
> ..
> 
> and the svn bridge to github probably doesn't work exactly the same as the
> native svn repo used to work, but I don't see it explicitly mentioned in:
> https://help.github.com/en/github/importing-your-projects-to-github/support-for-subversion-clients
> 
> So to resolve this quickly I'm going to send SRC_URI updates for
> these recipes to just use git fetcher from:
> https://github.com/openmoko/openmoko-svn
> directly. I don't think anyone is using these nowadays, so it's
> also fine with me to just delete them all, which I'll do in
> separate follow-up commit in case someone tries to resurrect them
> later in own layer.
> 

I think plan looks good. Lets fix the SRC_URI and then delete them