**** BEGIN LOGGING AT Thu May 21 02:59:57 2020
May 21 03:00:37 <owrt-snap-builds> build #327 of lantiq/xrx200 is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxrx200/builds/327  blamelist: Rosen Penev <rosenp@gmail.com>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Thibaut VAR?NE <hacks@slashdirt.org>
May 21 03:26:59 <owrt-snap-builds> build #371 of ramips/rt288x is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt288x/builds/371  blamelist: Rosen Penev <rosenp@gmail.com>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Thibaut VAR?NE <hacks@slashdirt.org>
May 21 03:28:17 <ashkan> is it me or the x86 images are broken ? https://imgur.com/a/vBi2MDj
May 21 03:29:39 <ashkan> I've tried both openwrt-x86-generic-generic-ext4-combined.img openwrt-x86-64-generic-ext4-combined.img
May 21 06:18:15 <ynezz> pkgadd: thanks!
May 21 06:20:11 <ynezz> Hauke: would be nice if you could push that 5.7-rc3 backports update soon, as this hostapd + mac80211 combination was tested :)
May 21 07:03:55 <owrt-snap-builds> build #119 of bcm27xx/bcm2711 is complete: Failure [failed dirupload]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2711/builds/119  blamelist: Petr ?tetiar <ynezz@true.cz>, Jason A. Donenfeld <Jason@zx2c4.com>
May 21 08:36:05 <aparcar[m]> is Felix Fietkau sometimes around?
May 21 08:36:54 <aparcar[m]> ashkan: are you using the latest x86 build? I've seen this issue a while ago but though it was fixed...
May 21 08:37:37 <ynezz> aparcar[m]: Felix has `nbd` nick here
May 21 08:42:34 <aparcar[m]> ynezz: thank you
May 21 08:43:27 <aparcar[m]> ynezz: I made some docker patches which are no longer automatically tested as gitlab deactivated GitHub integration in their free accounts :/ if you have the time please have a look, nothing big nor important
May 21 08:46:37 <rmilecki> i have netifd randomly crashing when starting
May 21 08:46:46 <rmilecki> it seems to be regression in v19.07.2
May 21 08:47:03 <rmilecki> it's caused by 65030d81f3df ("libubox: update to latest Git HEAD")
May 21 08:47:55 <rmilecki> which adds crashing commit 75e300aeec25 ("blobmsg: fix wrong payload len passed from blobmsg_check_array") https://git.openwrt.org/?p=project/libubox.git;a=commitdiff;h=75e300aeec25e032a9778bea34c713969960d1f0
May 21 08:48:43 <rmilecki> from a quick check it seems that blobmsg_len() which was used previously - it calls blobmsg_data_len() which takes care of attr = NULL
May 21 08:49:06 <rmilecki> blob_len() which is now used doesn't check for attr being NULL
May 21 08:49:18 <rmilecki> that is my early guess for a crash reason, I'm going to do more debugging now
May 21 08:49:23 <rmilecki> jow: ^^
May 21 08:49:54 <aparcar[m]> nbd: I'm trying to make more OpenWrt packages reproducible and libstdcpp6 stores the build path in a created python files which seems a bit uncommon. The file is called ./usr/lib/libstdc++.so.6.0.25-gdb.py  and I can't really find it in the build root, do you have an idea? The diff between my rebuild and the original file is here
May 21 08:49:54 <aparcar[m]> https://aparcar.gitlab.io/-/openwrt-rebuilder/-/jobs/559578399/artifacts/results/snapshots/targets/x86/64/packages/libstdcpp6_8.4.0-2_x86_64.ipk.html
May 21 09:33:54 <plntyk> aparcar[m] i think lynxis does more reproducible build commits - what do you mean you cant find that file ?
May 21 09:34:27 <plntyk> its both in the root-x86 target or the toolchain dir
May 21 09:34:29 <aparcar[m]> plntyk: I don't understand/find how/where the file is created
May 21 09:34:34 <plntyk> ah
May 21 09:37:57 <plntyk> so somewhere in gcc build system
May 21 09:39:51 <aparcar[m]> No clue, really. However if you find something please let me know :)!
May 21 09:41:00 <plntyk> build_dir/toolchain-<arch>/gcc-<ver>-final>/<arch>-openwrt-linux-musl>/libstdc++-v3/python/ has gdb.py
May 21 09:41:07 <plntyk> an generated Makefile
May 21 09:46:41 <plntyk> aparcar[m]: the gdb.py file probably is generated in https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libstdc%2B%2B-v3/python;hb=HEAD
May 21 09:46:59 <plntyk> hook.in has the path names with macro
May 21 09:47:29 <plntyk> that are then probably changed to sth different that you posted in your diff i think
May 21 09:49:08 <aparcar[m]> plntyk: amazing here it is! https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/python/hook.in;h=31a96b30db43d87fb0c7ba7b8c68cc0ea79e00ac;hb=HEAD#l22
May 21 09:49:20 <aparcar[m]> now I just have to figure out how to make it reproducible :)
May 21 09:49:37 <aparcar[m]> adrianschmutzler: btw aren't you active at freifunk?
May 21 09:53:10 <Borromini> aparcar[m]: his commit e-mail is freifunk@personal_domain :)
May 21 09:53:38 <aparcar[m]> Borromini: ahh right. adrianschmutzler may I ask which community?
May 21 09:54:45 <plntyk> aparcar[m], not an expert in gcc/gdb but this lib...-gdb.py is probably for debugging a system with gdb - so having the buildbot path in that file should always be wrong and will result in non function
May 21 09:56:05 <plntyk> one could sed the python file in install / post-install hooks
May 21 09:56:53 <aparcar[m]> plntyk: seems like there was some work here https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=35204bbe768b28492d9d36978291779ed18d0ed7;hp=a567fa6a3d2847584d38c4cee35e2273c8315013
May 21 09:56:53 <aparcar[m]> I'll try to make sense out of it
May 21 09:56:56 <plntyk> but dunno if that is the right thing - because the gdb file might be just for remote debugging
May 21 09:58:41 <plntyk> is there even a use case for having that file on a router for example
May 21 10:00:36 <aparcar[m]> I don't know
May 21 10:22:44 <Hauke> ynezz: ok will do
May 21 11:14:17 <f00b4r0> ha, too bad a860fe2304 didn't make it in time for 19.07 :)
May 21 11:15:20 <zorun> yeah, another reason calling for a 19.07.4 release not too far in the future
May 21 11:15:36 <zorun> anyway, whatever the date of a release, things will be missed :)
May 21 11:15:49 <f00b4r0> heh, true :)
May 21 11:48:30 <russell--> hmm. wgt634u r13317-ga860fe2304 seems to have broken ethernet, swconfig list sees nothing
May 21 11:48:47 <russell--> brcm47xx
May 21 11:50:48 <rmilecki> russell--: i'm still debugging that netifd problem, I can't look at that now
May 21 11:50:52 <rmilecki> russell--: anything interesting in dmesg?
May 21 11:51:55 <russell--> not that i've found
May 21 11:56:54 <russell--> rmilecki:
May 21 11:56:55 <russell--> [    1.478440] libphy: Fixed MDIO Bus: probed
May 21 11:56:55 <russell--> [    1.483609] b44: Broadcom 44xx/47xx 10/100 PCI ethernet driver version 2.0
May 21 11:56:58 <russell--> [    1.490980] b44 ssb0:0: Required 30BIT DMA mask unsupported by the system
May 21 11:57:37 <rmilecki> oh, i have bgmac devices only, so wouldn't see that anyway
May 21 11:57:51 <rmilecki> some old kernel update was messing with DMA
May 21 12:01:18 <russell--> the last time i built for this device was r12238-gdc145de4be back in february, seemed okay then (just to put a bracket on it)
May 21 12:02:01 <rmilecki> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=321c46b91550adc03054125fa7a1639390608e1a ("MIPS: BCM47XX: Setup struct device for the SoC")
May 21 12:02:02 <rmilecki> https://patchwork.kernel.org/patch/10773505/ ("[wireless-drivers-next] bcma: get SoC device struct & copy its DMA params to the subdevices")
May 21 12:02:09 <rmilecki> i don't remember how it ended right now
May 21 13:57:03 <Borromini> hey guys. i'm adding support for the WNDR4300SW, identical to the WNDR4300 except for the BOARD_ID. do the scripts in base-files look at the DEVICE_MODEL value somehow or do i need to add the model to 01_leds, 02_network etc. as well?
May 21 13:57:12 <Borromini> patch for the Makefile: https://paste.debian.net/1148141/
May 21 13:57:32 <Borromini> i can see e.g. the wndr4300-v2 etc is explicitly listed in those scripts as well.
May 21 14:07:50 <f00b4r0> if it's identical, does it really deserve its own image?
May 21 14:08:08 <ynezz> neoraider: FYI I've just pushed one libubox fix (https://git.openwrt.org/89fb6136ad7484e4e8f9b618e530e098cf573665) but I'm not going to bump libubox package in the tree as I'm aware about your planned fix/bump in the queue
May 21 14:08:12 <adrianschmutzler> base-files will use what's in the compatible of the DTS
May 21 14:09:05 <adrianschmutzler> which in turn has to match the define node in image/*, just with "," replaced by "_"
May 21 14:10:03 <ynezz> neoraider: s/in the queue/you've in the queue/
May 21 14:10:27 <adrianschmutzler> and you should decide whether the SW is part of the name, i.e. no space between, and part of DEVICE_MODEL or whether it's a variant, then you should add a hyphen for the name and compatible: netgear_wndr4300-sw
May 21 14:10:34 <adrianschmutzler> ^ Borromini
May 21 14:11:09 <adrianschmutzler> and yes, everything needs to be duplicated, DTS and base-files
May 21 14:11:35 <f00b4r0> that sounds suboptimal
May 21 14:11:44 <f00b4r0> at least use a DTSI
May 21 14:12:06 <f00b4r0> I'm wondering if we couldn't adapt the build system to gracefully handle devices symlinks
May 21 14:12:26 <adrianschmutzler> f00b4r0: DTSI is already there, the DTS is already trivial right now
May 21 14:12:31 <f00b4r0> ah ok
May 21 14:12:49 <adrianschmutzler> And I would have meant to create a DTSI anywhere, just made a short text as I'm on the jump
May 21 14:12:56 <rmilecki> ynezz: neoraider: i'm working on libubox regression that broke procd (re)stargint netifd
May 21 14:13:04 <rmilecki> *restarting
May 21 14:14:43 <ynezz> rmilecki: do you've reproducer?
May 21 14:14:51 <rmilecki> rmilecki: i had
May 21 14:15:01 <rmilecki> once I added some debugging it works cleanly
May 21 14:15:10 <ynezz> fixed, nice! :)
May 21 14:15:12 <rmilecki> basically: /etc/init.d/network restart
May 21 14:15:26 <rmilecki> over and over, reboot if it works and doesn't want to fail
May 21 14:15:27 <ynezz> I mean, dump of that blob
May 21 14:15:51 <rmilecki> no, working on it
May 21 14:16:06 <neoraider> ynezz: okay - the libubox/ucert fixes are not urgent for me, I don't actually use ucert. We just need to make sure the my libubox fix doesn't get in without the ucert patchset to avoid a security regression
May 21 14:16:56 <f00b4r0> speaking of procd, I noticed this after booting an upgrade from 18.06 to 19.07:
May 21 14:16:56 <f00b4r0> [   50.724094] procd: cannot set group dialout for /dev/ttyS11 (getgrnam: 0)
May 21 14:17:11 <f00b4r0> as well as: [   52.743835] random: ubusd: uninitialized urandom read (4 bytes read)
May 21 14:17:16 <f00b4r0> looks harmless though odd.
May 21 14:17:20 <neoraider> ynezz: I intend to push the usign fingerprint length fix soon and update the usign package in master and 19.07, as that is actually breaking builds
May 21 14:17:24 <adrianschmutzler> Borromini: just take that as a blueprint: https://github.com/openwrt/openwrt/commit/00ed75f47f4726dff17c6d63d6847bc4f7a74970
May 21 14:18:21 <ynezz> rmilecki: so that network restart crashes procd or netifd?
May 21 14:18:39 <ynezz> ah, reboot = procd
May 21 14:18:45 <rmilecki> ynezz: procd fails to start netifd
May 21 14:19:03 <rmilecki> ynezz: procd fails to start netifd
May 21 14:26:59 <owrt-snap-builds> build #372 of ramips/rt288x is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt288x/builds/372
May 21 14:38:49 <ynezz> aparcar[m]: bummer, but thats what we get for using "free" services, which sometimes^Walways change their usage terms/plans
May 21 14:55:10 <Borromini> anyone? :)
May 21 14:56:50 <owrt-snap-builds> build #373 of kirkwood/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/kirkwood%2Fgeneric/builds/373
May 21 14:56:53 <kristrev_> Hi. Does anyone know if there is a way to run multiple processes (multiple calls to rpc_exec()) after one another from an rpcd plugin? rpc_exec_reply seems quite definite, but I have probably overlooked something
May 21 14:57:31 <kristrev_> What I am trying to do is to run "wifi config" and then "wifi reload" from plugin
May 21 14:58:46 <kristrev_> When I do try, rpcd seems to hang until the first process times out on roughly every other rpc call
May 21 15:07:46 <f00b4r0> xback: successful test report of the sysfs soft_config driver is successful ;) I'll open a PR
May 21 15:14:17 <PaulFertser> Borromini: if it'll be using different "compatible" board string in the DT and then it'll have different ID in /etc/board.json and then it won't match in scripts.
May 21 15:26:21 <owrt-snap-builds> build #328 of lantiq/xrx200 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxrx200/builds/328
May 21 15:37:29 <owrt-snap-builds> build #304 of mpc85xx/p2020 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp2020/builds/304  blamelist: Petr ?tetiar <ynezz@true.cz>, Hauke Mehrtens <hauke@hauke-m.de>, Daniel Golle <daniel@makrotopia.org>, Russell King <linux@armlinux.org.uk>, Jason A. Donenfeld <Jason@zx2c4.com>
May 21 17:04:37 <owrt-snap-builds> build #326 of mpc85xx/p1020 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1020/builds/326  blamelist: Petr ?tetiar <ynezz@true.cz>, Hauke Mehrtens <hauke@hauke-m.de>, Daniel Golle <daniel@makrotopia.org>, Russell King <linux@armlinux.org.uk>, Jason A. Donenfeld <Jason@zx2c4.com>
May 21 18:36:29 <danitool> [florian]: ping
May 21 19:45:27 <[florian]> danitool: pong
May 21 19:52:23 <danitool> [florian]: I am trying to fix the mvneta patch disaster, do you think this functions could be enough in phylink?
May 21 19:52:26 <danitool> https://bpa.st/LXJQ
May 21 19:55:24 <danitool> I'm not sure what happens when an external switch is attached, but it is working ok on my device
May 21 20:10:40 <[florian]> that's a good start
May 21 20:16:54 <owrt-snap-builds> build #120 of bcm27xx/bcm2711 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2711/builds/120
May 21 20:22:31 <owrt-snap-builds> build #118 of bcm27xx/bcm2708 is complete: Failure [failed dirupload]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2708/builds/118  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Daniel Golle <daniel@makrotopia.org>, Hans Dedecker <dedeckeh@gmail.com>, Philip Prindeville <philipp@redfish-solutions.com>,
May 21 20:22:31 <owrt-snap-builds> Russell King <linux@armlinux.org.uk>, Hauke Mehrtens <hauke@hauke-m.de>
May 22 02:28:22 <owrt-snap-builds> build #329 of lantiq/xrx200 is complete: Failure [failed dirupload]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxrx200/builds/329  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Hans Dedecker <dedeckeh@gmail.com>, Hauke Mehrtens <hauke@hauke-m.de>, Philip Prindeville <philipp@redfish-solutions.com>
**** ENDING LOGGING AT Fri May 22 02:59:57 2020