**** BEGIN LOGGING AT Mon May 11 02:59:57 2020 May 11 04:06:40 build #103 of bcm27xx/bcm2709 is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2709/builds/103 blamelist: David Bauer , Kevin Darbyshire-Bryant May 11 04:53:10 build #49 of ath79/mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fmikrotik/builds/49 May 11 05:07:06 build #103 of bcm47xx/mips74k is complete: Failure [failed dirupload] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Fmips74k/builds/103 blamelist: David Bauer , Kevin Darbyshire-Bryant May 11 05:14:09 build #29 of rockchip/armv8 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/rockchip%2Farmv8/builds/29 May 11 05:45:26 build #96 of bcm27xx/bcm2710 is complete: Failure [failed fetchrefs] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2710/builds/96 blamelist: David Bauer , Kevin Darbyshire-Bryant May 11 05:56:44 stintel, ping May 11 07:54:13 I just learned about https://www.kernel.org/doc/html/v4.12/admin-guide/ramoops.html May 11 07:54:58 wonder if we get rid of our crashlog stuff in favor to that May 11 07:58:26 pkgadd: thanks for testing that hostapd bumpd, but from your emails it's not clear to me if it actually works and the only "drawback" is the log splat every 3 seconds May 11 07:59:01 as Hauke found out, we can't do much about it in the userspace/hostapd, probably just limit/disable the chatty warning logging May 11 07:59:34 maybe bump the log level? we already patch hostapd to compile out all messages above a certain threshhold May 11 07:59:53 or below, depending on the perspective May 11 08:02:34 build #394 of sunxi/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa53/builds/394 May 11 08:09:55 lynxis: hey, i was curious about poster reproducible link but this https://tests.reproducible-builds.org/openwrt/openwrt_brcm47xx.html uses ath79 despite its name May 11 08:17:23 jow: lets see http://lists.infradead.org/pipermail/hostap/2020-May/041679.html May 11 08:21:04 ynezz: ah great May 11 10:27:35 build #364 of apm821xx/sata is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fsata/builds/364 May 11 10:48:32 build #366 of ath79/nand is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fnand/builds/366 May 11 11:22:35 build #359 of at91/sama5 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsama5/builds/359 May 11 12:13:15 ynezz: hostapd itself is working, it's just the endless stream of warnings reoeating every 3s (which should be muted by your patch). sorry that I've been unclear about that May 11 12:43:24 build #351 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/351 May 11 12:55:08 does anyone know why some of the snapshot image are "403 Forbidden" for example https://downloads.openwrt.org/snapshots/targets/mpc85xx/p1020/openwrt-mpc85xx-p1020-enterasys_ws-ap3710i-initramfs-kernel.bin May 11 13:08:31 pmelange: I'd guess that some utility (mkuimage or a kernel make target) outputs files with restrictive permissions (0600) which are then rsynced as-is May 11 13:10:38 jow that's unfortunate. Oh well, I can also the images myself May 11 13:37:27 build #365 of ramips/rt3883 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/365 May 11 13:59:34 jow: maybe we could add a --chmod= parameter to rsync to work around that (although that's only a workaround, not a fix :) May 11 14:27:29 uhm, why was this arm_cortex-a9_vfpv3-d16 nonesense backported to 19.07 ? May 11 14:28:04 its very unfortunate to change cpu and package arches midway during a release May 11 14:34:35 :-/ May 11 14:36:41 jow: otherwise, tegra images and part of mvebu cortexa9 images with armada 370 are broken, I'm fine with reverting that, but please do write warning in release notes. May 11 14:59:05 so it was broken in all 19.07 release so far? May 11 14:59:19 or is that something that happened with a kernel bump? May 11 15:02:35 the offending commit (8dcc1087602e) was introduced a few months before the 19.07 branching May 11 15:09:48 hmm. My ISP seems to be experiencing some "difficulties" :P May 11 15:10:49 why was the existing arm_cortex-a9_vfpv3 designation changed to arm_cortex-a9_vfpv3-d16 ? May 11 15:13:51 seems to fix a regression introduced by 8dcc1087602e May 11 15:14:11 why was the direct CPU_CFLAGS mapping removed in favor to brittle gcc defaults? May 11 15:21:42 it also appears that 8dcc1087602e removed the only actual user of $(CPU_SUBTYPE) May 11 15:22:33 nvm May 11 15:22:52 jow: yes it was broken in 19.07 from beginning May 11 15:24:06 https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=8dcc1087602e2dd606e4f6e81a06aee62cfd4f4c looks broken to me May 11 15:25:16 the cpu subtype (the part after the "+" in CONFIG_CPU) was clearly not meant to be passed as-is to gcc but it was mean to be resolved to a -mfpu... or whatever value through an CPU_FLAGS_$(subtype expression) mapping May 11 15:26:12 it also removed the very part that mapped "vfpv3" to an explicit "vfpv3-d16" to address this very issue May 11 15:27:59 yes, but why was that preffered, I don't know. Seems like discusion was on GitHub PR where I rarely look. May 11 15:28:08 by removing the indirection we'll keep running into problems like that whenever gcc changes its defaults May 11 15:31:30 build #356 of armvirt/32 is complete: Failure [failed dirupload] Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F32/builds/356 blamelist: David Bauer May 11 15:33:47 jow: PR#1913, I don't know how often the gcc defaults change, for arm 32bit I think they won't, since there likely won't be new cores introduced, so should be safe. For the others that's possible. May 11 15:36:17 build #360 of mediatek/mt7623 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7623/builds/360 May 11 15:40:16 jow: https://github.com/openwrt/openwrt/pull/1913#issuecomment-474892856 and https://github.com/openwrt/openwrt/pull/1913#issuecomment-475071884 seems like was Christians reasoning. May 11 15:50:36 rmilecki: thanks. i'll take a look into. i would guess it's the config became invalid. May 11 16:26:55 rmilecki: https://salsa.debian.org/qa/jenkins.debian.net/-/commit/fbe011d754c603836f0eb8b050659e0132a9f48c May 11 16:54:45 lynxis: ah, rename is a strong reason for breakage ;) thanks for fixing May 11 17:08:55 tmn505_: thanks for the pointers May 11 17:46:40 build #356 of x86/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeneric/builds/356 May 11 18:26:28 build #350 of archs38/generic is complete: Failure [failed dirupload] Build details are at http://buildbot.openwrt.org/master/images/builders/archs38%2Fgeneric/builds/350 blamelist: Koen Vandeputte , David Bauer May 11 18:32:24 is there an example of a router that uses squashfs with nand-flash + ubifs, so that factory reset works as it does with a nor-flash router (squashfs+jffs2)... is it that the right approach I should be trying to get working for a new nand-flash device? May 11 18:34:00 bemo: that's actually the way most nand targets do. May 11 18:34:53 bemo: with squashfs on a ubi partition. May 11 18:36:46 sorry... still new to openwrt and adding new device support... was looking for an example that already does it and/or documentation on how to do it the "right" way... i.e., should I define my partitions with specific names so the existing scripts build it as desired? May 11 18:38:05 (and how do I install it correctly once I have the image? sounds like the way it's done on nor-flash is there's a special flag in the filesystem at the end of the squashfs partition, so the second data partition can be discovered and/or erased reformatted upon a factory reset) May 11 18:40:14 bemo: the relevant sysupgrade code is in ./base-files/files/lib/upgrade/nand.sh May 11 18:40:40 PaulFertser: thank you for the pointer... I'll keep poking May 11 18:56:43 on a semi-related note... is there anything special I need to do to get sysupgrade to work? (my existing image seems to be complaining about "fwtool_check_signature" failing) May 11 19:03:26 (when starting to investigate, it appeared there was a tool called "ucert" which was not installed... after installing it, it still fails, but it got me to thinking I'm probably missing a bigger picture here... like the image needs to be signed and/or I'm missing the right tools to install the image) May 11 19:03:33 bemo: https://git.openwrt.org/d0090339117031d1994d139240bb30cb39b73060 example, nothing fancy there May 11 19:04:13 PaulFertser awesome - thank you! May 11 19:27:48 build #361 of kirkwood/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/kirkwood%2Fgeneric/builds/361 May 11 19:35:10 Hauke: ping May 11 19:35:54 we got accepted for the google season of docs, however need two more mentors. May 11 19:38:58 aparcar[m]: pong May 11 19:41:57 We need two people mentoring a single writer May 11 19:42:11 Anyone comes to your mind? May 11 20:24:52 build #348 of omap/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/omap%2Fgeneric/builds/348 May 11 20:31:42 aparcar[m]: do we have two technical writer? May 11 20:34:02 build #360 of ramips/rt288x is complete: Failure [failed dirupload] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt288x/builds/360 blamelist: Koen Vandeputte , David Bauer May 11 20:50:38 Hauke: writers apply to the program and we can chose them. So likely more than 2 candidates May 11 20:51:16 jow: you made me day with `f2166a8 libopkg: implement lightweight package listing logic`! May 11 20:53:31 Hauke: aparcar[m]: writers: maybe BluseBlue (Thomas Huehn)? May 11 20:58:15 ok May 11 21:56:55 build #317 of bcm53xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm53xx%2Fgeneric/builds/317 May 11 22:28:13 build #316 of lantiq/xrx200 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxrx200/builds/316 May 12 00:28:58 build #104 of bcm27xx/bcm2709 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2709/builds/104 May 12 01:24:30 build #104 of bcm47xx/mips74k is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Fmips74k/builds/104 May 12 01:45:39 build #103 of bcm47xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Fgeneric/builds/103 May 12 02:26:07 build #104 of bcm27xx/bcm2711 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2711/builds/104 **** ENDING LOGGING AT Tue May 12 03:00:16 2020