phase1: 23.05: qualcommax should not be built

[robimarko]

qualcommax is a renamed ipq807x target with ipq807x now as a subtarget, and its only present in master but buildbots are trying to build it for 23.05 as well.

Builder: https://buildbot.staging.openwrt.org/images/#/builders/167

This should not be happening as output of ./scripts/dump-target-info.pl targets does not list qualcommax on 23.05:

apm821xx/nand powerpc_464fp
apm821xx/sata powerpc_464fp
armsr/armv7 arm_cortex-a15_neon-vfpv4
armsr/armv8 aarch64_generic
at91/sam9x arm_arm926ej-s
at91/sama5 arm_cortex-a5_vfpv4
at91/sama7 arm_cortex-a7_vfpv4
ath79/generic mips_24kc
ath79/mikrotik mips_24kc
ath79/nand mips_24kc
ath79/tiny mips_24kc
bcm27xx/bcm2708 arm_arm1176jzf-s_vfp
bcm27xx/bcm2709 arm_cortex-a7_neon-vfpv4
bcm27xx/bcm2710 aarch64_cortex-a53
bcm27xx/bcm2711 aarch64_cortex-a72
bcm47xx/generic mipsel_mips32
bcm47xx/legacy mipsel_mips32
bcm47xx/mips74k mipsel_74kc
bcm4908/generic aarch64_cortex-a53
bcm53xx/generic arm_cortex-a9
bcm63xx/generic mips_mips32
bcm63xx/smp mips_mips32
bmips/bcm6318 mips_mips32
bmips/bcm63268 mips_mips32
bmips/bcm6328 mips_mips32
bmips/bcm6358 mips_mips32
bmips/bcm6362 mips_mips32
bmips/bcm6368 mips_mips32
gemini/generic arm_fa526
imx/cortexa7 arm_cortex-a7_neon-vfpv4
imx/cortexa9 arm_cortex-a9_neon
ipq40xx/chromium arm_cortex-a7_neon-vfpv4
ipq40xx/generic arm_cortex-a7_neon-vfpv4
ipq40xx/mikrotik arm_cortex-a7_neon-vfpv4
ipq806x/chromium arm_cortex-a15_neon-vfpv4
ipq806x/generic arm_cortex-a15_neon-vfpv4
ipq807x/generic aarch64_cortex-a53
kirkwood/generic arm_xscale
lantiq/ase mips_mips32
lantiq/xway mips_24kc
lantiq/xway_legacy mips_24kc
layerscape/armv7 arm_cortex-a7_neon-vfpv4
layerscape/armv8_64b aarch64_generic
malta/be mips_24kc
mediatek/filogic aarch64_cortex-a53
mediatek/mt7622 aarch64_cortex-a53
mediatek/mt7623 arm_cortex-a7_neon-vfpv4
mediatek/mt7629 arm_cortex-a7
mpc85xx/p1010 powerpc_8548
mpc85xx/p1020 powerpc_8548
mpc85xx/p2020 powerpc_8548
mvebu/cortexa53 aarch64_cortex-a53
mvebu/cortexa72 aarch64_cortex-a72
mvebu/cortexa9 arm_cortex-a9_vfpv3-d16
mxs/generic arm_arm926ej-s
octeon/generic mips64_octeonplus
octeontx/generic aarch64_generic
oxnas/ox820 arm_mpcore
pistachio/generic mipsel_24kc_24kf
ramips/mt7620 mipsel_24kc
ramips/mt7621 mipsel_24kc
ramips/mt76x8 mipsel_24kc
ramips/rt288x mipsel_24kc
ramips/rt305x mipsel_24kc
ramips/rt3883 mipsel_74kc
realtek/rtl838x mips_4kec
realtek/rtl839x mips_24kc
realtek/rtl930x mips_24kc
realtek/rtl931x mips_24kc
rockchip/armv8 aarch64_generic
sifiveu/generic riscv64_riscv64
sunxi/cortexa53 aarch64_cortex-a53
sunxi/cortexa7 arm_cortex-a7_neon-vfpv4
sunxi/cortexa8 arm_cortex-a8_vfpv3
tegra/generic arm_cortex-a9_vfpv3-d16
x86/64 x86_64
x86/generic i386_pentium4
x86/geode i386_pentium-mmx
x86/legacy i386_pentium-mmx
zynq/generic arm_cortex-a9_neon

[robimarko]

@f00b4r0 You got any ideas as it seems that ./scripts/dump-target-info.pl targets is leaking also from 23.05 to master as ipq807x builder was created again despite it not existing anymore in master.

[f00b4r0]

@robimarko I honestly don't. If you look at populateTargets() it starts from a clean clone for each branch so unless the "leak" is committed I can't explain that.

[ynezz]

If you look at populateTargets() it starts from a clean clone for each branch so unless the "leak" is committed I can't explain that.

From the quick look it seems, that targets = set() is not taking branch into the account.

[f00b4r0]

Ah yes I remember the logic now: find the exhaustive list of all targets and let the "checkarch" step do the final triaging. Not sure why this doesn't work as intended. I'm looking at this from smartphone so maybe I'm missing something obvious, no access to computer before next Monday.

[f00b4r0]

So i just looked at the linked build log and it is working exactly as intended: checkarch interrupts the build as designed. Please close this, there's no bug here.

[robimarko]

Ok, having builders for targets that dont exist looked like a bug to ynezz and I.

[ynezz]

Ah yes I remember the logic now: find the exhaustive list of all targets and let the "checkarch" step do the final triaging.

Ok, thanks for looking into that, is there any specific reason why its being done that way? I'm probably missing something :)

checkarch interrupts the build as designed.

Ok, but we know upfront, that it's not going to work, so why to waste resources on this?

Please close this, there's no bug here.

I would prefer to improve it https://github.com/openwrt/buildbot/pull/15

[f00b4r0]

Ah yes I remember the logic now: find the exhaustive list of all targets and let the "checkarch" step do the final triaging.

Ok, thanks for looking into that, is there any specific reason why its being done that way? I'm probably missing something :)

Other than "I probably didn't know better", and "it seemed expected practice" (given the preexisting checkarch step which is moot if we correctly setup builders), I guess not :)

checkarch interrupts the build as designed.

Ok, but we know upfront, that it's not going to work, so why to waste resources on this?

We're talking about 3mn out of typically 2h40 build. That's just under 2% of expected time, i.e. 98% savings, so let's not overreact here maybe? :)

I'm actually more concerned that defconfig seems to take anywhere from 40s to a full minute to run. That's definitely odd, it shouldn't be that slow..

Please close this, there's no bug here.

I would prefer to improve it #15

Looking at it now.