**** BEGIN LOGGING AT Thu Apr 30 02:59:57 2020
Apr 30 04:33:02 <owrt-snap-builds> build #289 of samsung/s5pv210 is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/samsung%2Fs5pv210/builds/289  blamelist: Daniel Golle <daniel@makrotopia.org>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, David Bauer <mail@david-bauer.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-
Apr 30 04:33:02 <owrt-snap-builds> bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>
Apr 30 04:34:23 <owrt-snap-builds> build #284 of ramips/mt7620 is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7620/builds/284  blamelist: Daniel Golle <daniel@makrotopia.org>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, David Bauer <mail@david-bauer.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-
Apr 30 04:34:23 <owrt-snap-builds> bryant.me.uk>, Petr ?tetiar <ynezz@true.cz>
Apr 30 04:36:02 <mangix> interesting
Apr 30 04:36:15 <mangix> people compile OpenWrt on systems that have GCC4
Apr 30 04:36:29 <mangix> wonder if this should really be supported
Apr 30 04:45:28 <ynezz> mangix: http://lists.infradead.org/pipermail/openwrt-devel/2019-November/020034.html
Apr 30 04:45:47 <ynezz> I plan to push that patch after 20.y release
Apr 30 05:09:31 <plntyk> there are still gcc4 toolchains available from linaro too
Apr 30 05:09:41 <plntyk> https://releases.linaro.org/components/toolchain/binaries/
Apr 30 05:14:08 <mangix> main problem with GCC4 and less is gnu89 is default
Apr 30 05:14:17 <mangix> and that breaks some host packages
Apr 30 05:14:31 <mangix> there is the other issue with C++
Apr 30 05:14:48 <mangix> GCC6 and less do not support C++17
Apr 30 05:17:46 <mangix> Hmm I don't see anything requiring C++17 in the packages feed
Apr 30 05:18:03 <plntyk> new and improved programming languages and features
Apr 30 05:18:22 <mangix> I know what it is
Apr 30 05:18:39 <mangix> but no HostBuild packages need it
Apr 30 05:19:04 <mangix> Maybe there's one or two needing C++14 but I doubt it
Apr 30 05:19:23 <plntyk> for example mpd - music player daemon switched from C to C++ probably with a developer switch
Apr 30 05:19:51 <mangix> Yeah I contribute to MPD. It's a C++17 project
Apr 30 05:22:11 <plntyk> many vendors are probably keeping their *very* old code base /BSP packages because "it just works" in their workflow
Apr 30 05:22:54 <plntyk> from a theoretical standpoint all of those are turing-complete anyway ^^
Apr 30 05:23:08 <plntyk> just nobody using COBOL-embedded
Apr 30 06:14:28 <mangix> cmake not compiling on alpine linux :)
Apr 30 06:15:15 <mangix> probably a version update will fix it...
Apr 30 06:15:35 <mangix> ah no. it has a dependency on linux-headers
Apr 30 06:19:55 <mangix> now e2fsprogs fails
Apr 30 06:20:00 <mangix> eh w/e. another day.
Apr 30 09:15:11 <aparcar[m]> Should OpenWrt apply for this? Google pays students (any age) to write project documentation. https://developers.google.com/season-of-docs/ Kind of like Summer of Code but for docs
Apr 30 10:05:49 <owrt-snap-builds> build #277 of ipq40xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ipq40xx%2Fgeneric/builds/277
Apr 30 10:16:46 <ynezz> KanjiMonster: https://bugs.openwrt.org/index.php?do=details&task_id=2202 ("brcm63xx: Hg556a: 4.14 kernel boot stuck at "random: crng init done") could you please take a look at this once you've some time? There is finally some capable and persistent guy who could possibly find out where its broken, just needs some pointers
Apr 30 10:17:10 <ynezz> KanjiMonster: he's able to reproduce it even on 5.4.36
Apr 30 10:19:17 <ynezz> unfortunately he has bisected it to "2308b87204206d84b6bf3dbc3d72591611cc6b78 brcm63xx: switch to 4.14", which is deep rabit hole
Apr 30 14:03:34 <Hauke> aparcar[m]: if someone is intrested to wrte OpenWrt documentation we can apply for this
Apr 30 14:03:48 <Hauke> at least I would approve this, but currently I do not have the time for all this paperwork
Apr 30 14:04:43 <Hauke> if you want to apply for writing the documentation or know someone it would be nice
Apr 30 14:18:14 <gromero> hi, does anybody know what might be going on on this Archer C50 boot: https://pastebin.com/raw/NFSiDMjk ?
Apr 30 14:18:26 <gromero> it just get stuck, but I'm not sure if it's waiting some input actually
Apr 30 14:18:49 <gromero> *gets
Apr 30 14:20:56 <PaulFertser> gromero: is that how you got this unit?
Apr 30 14:21:34 <gromero> PaulFertser: sorry, what you mean?
Apr 30 14:22:25 <gromero> that is the state I have after some flash-burn going wrong if that's what you asked :)
Apr 30 14:22:58 <PaulFertser> gromero: yes, would be nice to see as much pre-history as possible.
Apr 30 14:23:27 <gromero> PaulFertser: oh just found on a commit message that I actually need to press '4' when booting to get the prompt: https://pastebin.com/raw/KNzTuhJ8
Apr 30 14:24:31 <gromero> PaulFertser: I'm actually trying to fix a long standing bug on 2.4GHz radio that render it useless
Apr 30 14:24:58 <PaulFertser> gromero: so with the prompt you can be booting initramfs images without flashing.
Apr 30 14:25:00 <gromero> so trying to find a workflow to build, burn and test openwrt images on that device
Apr 30 14:25:07 <PaulFertser> And testing whatever's needed to be tested.
Apr 30 14:25:42 <gromero> PaulFertser: let me see if I find the initramfs artifact after openwrt is built 1 sec
Apr 30 14:26:12 <PaulFertser> gromero: you might want to enable it in menuconfig
Apr 30 14:26:43 <gromero> PaulFertser: you mean I can flash that: openwrt-ramips-mt76x8-tplink_archer-c50-v4-initramfs-kernel.bin directly from Uboot prompt?
Apr 30 14:27:18 <PaulFertser> gromero: not flash
Apr 30 14:27:21 <PaulFertser> upload to SDRAM
Apr 30 14:27:24 <PaulFertser> and bootm
Apr 30 14:28:34 <gromero> got it. But how about the rootfs? how do I pass it? of the initramfs for openwrt has everything its necessary to boot until the final stage?
Apr 30 14:28:46 <gromero> btw, I have the following:
Apr 30 14:28:47 <gromero> gromero@gromero2:/mnt/git/openwrt$ fgrep -i initramfs .config | fgrep -v \#
Apr 30 14:28:47 <gromero> CONFIG_USES_INITRAMFS=y
Apr 30 14:28:47 <gromero> CONFIG_TARGET_ROOTFS_INITRAMFS=y
Apr 30 14:28:47 <gromero> CONFIG_TARGET_INITRAMFS_COMPRESSION_LZMA=y
Apr 30 14:28:57 <PaulFertser> gromero: that's the trick, rootfs is emebedded into initramfs!
Apr 30 14:29:12 <gromero> PaulFertser: ah! excellent :)
Apr 30 14:33:24 <gromero> PaulFertser: so, people reported that stock image from TP-link (original firmware) works. For testing purposes, all I need is to extract Uboot initial 200k-ish bytes for the beginning and use it as a initramfs? Any idea about it?
Apr 30 14:34:02 <gromero> (I really have no clue about what's inside the stock image, so I ask)
Apr 30 14:34:51 <PaulFertser> gromero: no, stock image requires flashing
Apr 30 14:35:12 <PaulFertser> gromero: any image that's not specifically initramfs requires flashing.
Apr 30 14:35:27 <gromero> damn :) I see
Apr 30 14:35:40 <gromero> but is it possible to flahs is using uboot ?
Apr 30 14:35:51 <PaulFertser> gromero: usually yes
Apr 30 14:36:01 <PaulFertser> gromero: erase.b , cp.b
Apr 30 14:36:11 <PaulFertser> gromero: but be super-careful to not overwrite the bootloader!
Apr 30 14:36:31 <PaulFertser> gromero: you can also flash whatever you want from initramfs.
Apr 30 14:36:36 <PaulFertser> And I'd say it's safer.
Apr 30 14:37:33 <gromero> so in theory it's possible to flash wrongly from uboot (the bootloader) and mess with uboot itself, right?
Apr 30 14:38:09 <gromero> I was unsure if burning the uboot is only possible through SPI, for instance
Apr 30 14:39:34 <gromero> and when you said I can flash whatever I want from initramfs, you mean after I boot Linux or using another payload / tool?
Apr 30 14:40:35 <gromero> I'm still trying to figure out the memory map for that device btw, so it's not clear right now to me where the flash is mapped on the real addresses...
Apr 30 14:45:54 <gromero> PaulFertser: ^
Apr 30 14:46:52 <PaulFertser> gromero: if you boot OpenWrt initramfs you'll have "mtd" tool at your disposal. And bootloader partition will be write-protected so not risky to flash anything you want.
Apr 30 14:47:32 <PaulFertser> gromero: SPI flash might be mapped for reading in bootloader. You can see it all in "printenv" probably.
Apr 30 14:48:54 <gromero> PaulFertser: thanks
Apr 30 15:04:16 <gromero> PaulFertser: https://pastebin.com/raw/gtY33W3s so, it seems some program is broken and I get a sigsegv quite earlier (probably init is busted) after the boot
Apr 30 15:04:23 <gromero> I'm using reboot-13104-g80a094aaf3
Apr 30 15:04:47 <gromero> do you know if I can pass a boot command line from bootm? like "init=/bin/sh" ?
Apr 30 15:05:37 <gromero> actually that's the sigsegv:
Apr 30 15:05:38 <gromero> do_page_fault(): sending SIGSEGV to jshn for invalid read access from 00000068
Apr 30 15:05:49 <gromero> so from 'jshn' program
Apr 30 15:07:15 <gromero> ... and of course it's related to json =/
Apr 30 15:08:43 <gromero> I probably messed up the build when trying to make it build with json on Ubuntu. nm.
Apr 30 15:10:29 <PaulFertser> gromero: most OpenWrt targets ignore boot command line
Apr 30 15:10:36 <PaulFertser> Because the bootloader are uncooperative.
Apr 30 15:12:04 <gromero> I see. yeah regarding my sigsegv it's probably something locally wrong with my setup. I had to do some tweaks to get openwrt building on Ubuntu 18.04 regarding json-c lib : /
Apr 30 15:12:49 <gromero> PaulFertser: which distro do you usually use to build OpenWRT?
Apr 30 15:17:53 <PaulFertser> gromero: Gentoo and Debian
Apr 30 15:18:14 <gromero> k
Apr 30 17:37:17 <Slimey> is there an option to copy the .config to the image at build time for future reference
Apr 30 18:22:46 <owrt-snap-builds> build #341 of layerscape/armv8_64b is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/341
Apr 30 18:32:19 <owrt-snap-builds> build #355 of ramips/rt3883 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/355
Apr 30 19:34:19 <f00b4r0> I see tmomas is creating a lot of mostly empty device pages which bring no more information that what can already be found in the ToH, I'm not sure that's really needed
Apr 30 19:42:34 <pkgadd> f00b4r0: he has probably been asked to help with creating them, as that's not exactly straight forward for a casual wiki user to do (and he did poll about the best strategy, e.g. full empty template of just a minimal page, before, the results of that suggested to go with the full template, to make it easier for contributors and to keep the pages roughly similar)
Apr 30 19:43:27 <f00b4r0> pkgadd: ah ok. I was under the impression he was maybe implementing some sort of policy whereby each device needed to have its own device page. Which I hope isn't the case ;)
Apr 30 19:47:46 <pkgadd> Hauke: I've been running your mac80211-5.6 update for almost 24 hours now, that seems to fix the SWBA overrun on ath10k (FS#2480); ath10k-ct also seems to work with the newer backports (only a quick test for that though). tested on ipq806x/ nbg6817 (2*qca9984) and ipq40xx/ map-ac2200 (2*ipq4019+qca9886) - works fine for me (also build-tested on ath79/ ath79-tiny and lantiq)
Apr 30 19:54:19 <Hauke> pkgadd: thanks for testing
Apr 30 19:57:15 <Hauke> pkgadd: if it fixes the "SWBA overrun" problem, it would be ncie to backport this to openwrt 19.07
Apr 30 19:58:35 <pkgadd> Hauke: I'm a bit hesitant to proclaim all clear yet, but it's indeed looking very good for me so far
Apr 30 19:59:43 <pkgadd> I had a busy WDS/ 4addr link between qca9984 and ipq4019 running all day
Apr 30 20:06:05 <Hauke> ok
Apr 30 20:06:46 <greearb> what was root cause of the SWBA overrun?
Apr 30 20:18:03 <pkgadd> greearb: sadly I have no idea, v4.14 based backports were fine, v4.19 and v5.4 based backports usually started a number of SWBA overruns within minutes, usually followed by a crash/ reboot within short time; ath10k-ct is not affected, just mainline ath10k
Apr 30 20:19:23 <pkgadd> and now the v5.7-rc2 backports seem to fix it again
Apr 30 20:20:10 <greearb> ahh, ok.  I see some ath10k-ct dmesg output with SWBA messages in it, but nothing too serious, and no obvious link to crashes.
Apr 30 20:22:12 <greearb> in case ath10k-ct users select the new trimmed HTT firmware, then we can also reliably build fwcfg files that will significantly improve the number of stations supported in AP mode.  I'm happy to provide fwcfg examples if someone would like to do the magic to auto-create the fwcfg files in case they are not already there when the driver is loaded?
Apr 30 20:24:45 <pkgadd> I don't think OpenWrt generates fwcfg files automatically
Apr 30 20:25:01 <pkgadd> mostly relying on the defaults
Apr 30 20:25:25 <greearb> correct, but if it did, out-of-the-box experience would be better
Apr 30 20:26:59 <greearb> I have a linksys supporting 228+ stations, for instance (should support closer to 400+, but my current test rig maxes out at 228)
Apr 30 20:28:11 <greearb> default behaviour is only like 32 stations, which is a bit small these days
Apr 30 20:28:20 <pkgadd> hehe, I have to clean out the shelves quite a bit (down to 802.11b gear) to get around half that much wireless devices running ;) (normally it's more in the 10-20 devices range)
Apr 30 20:29:31 <greearb> well, I'll give you testing software for non-commercial purposes that will give you huge numbers of stations if you want
Apr 30 20:29:44 <greearb> or sell you stuff for commercial work :)
Apr 30 20:30:10 <pkgadd> hehe, thanks, but not necessary - pretty boring home uses over here
Apr 30 20:32:30 <greearb> I'm working on some automated regression tests for openwrt APs for another project, so it will be tested one way or another.
Apr 30 20:32:56 <greearb> so far, rock solid on the Linksys
Apr 30 20:34:13 <pkgadd> yeah, I'm quite pleasantly surprised with my ipq4019/ qca9886 based map-ac2200 as well (antenna design --> range isn't that great, but it's a nice little device)
Apr 30 21:06:39 <stintel> sigh, here I am, yak shaving again
Apr 30 21:07:13 * DonkeyHotei hides the powdered toast
Apr 30 21:13:39 * mamarley hands stintel an electric trimmer.
Apr 30 21:16:48 <blogic> stintel: i cut my hair today myself
Apr 30 21:16:56 <blogic> and it actually looks really good
Apr 30 21:52:05 <stintel> /home/build/openwrt/staging_dir/toolchain-arm_arm1176jzf-s+vfp_gcc-8.4.0_musl_eabi/bin/../lib/gcc/arm-openwrt-linux-muslgnueabi/8.4.0/../../../../arm-openwrt-linux-muslgnueabi/bin/ld: readsb.o: in function `parse_opt':
Apr 30 21:52:05 <stintel> /home/build/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/readsb-3.8.2/readsb.c:773: undefined reference to `argp_usage'
Apr 30 21:52:05 <stintel> /home/build/openwrt/staging_dir/toolchain-arm_arm1176jzf-s+vfp_gcc-8.4.0_musl_eabi/bin/../lib/gcc/arm-openwrt-linux-muslgnueabi/8.4.0/../../../../arm-openwrt-linux-muslgnueabi/bin/ld: readsb.o: in function `main':
Apr 30 21:52:05 <stintel> /home/build/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/readsb-3.8.2/readsb.c:801: undefined reference to `argp_parse'
Apr 30 21:52:15 <stintel> any hints to solve this ?
Apr 30 21:54:59 <stintel> DEPENDS:=+argp-standalone doesn't help
Apr 30 22:30:38 <Hauke> stintel: you probably have to add this to the LDFLAGS
Apr 30 22:31:05 <Hauke> glibc provides argp_parse, so the application probably assumes that libc will provide it
Apr 30 22:31:34 <stintel> Hauke: yeah but argp is a common missing thing with musl. I figured we'd have something to automate that
Apr 30 22:31:53 <stintel> I added: TARGET_LDFLAGS += "-largp"
Apr 30 22:31:57 <stintel> and now seems to work
Apr 30 22:33:57 <Hauke> stintel: the DEPENDS is probably not needed beacause argp is a static lib
Apr 30 22:35:08 <stintel> Hauke: much appreciate your reply
Apr 30 22:35:49 <stintel> bleh, sysupgraded my rpi3a and getting the rainbow image on the monitor
Apr 30 22:36:03 * stintel continues shaving yaks 
Apr 30 22:36:55 <stintel> borken card reader doesn't help recovering from this situation
Apr 30 22:38:09 <stintel> but actually that broken card reader might actually not be broken
Apr 30 22:38:21 <stintel> just a 7y old KDE bug
Apr 30 22:38:34 <stintel> nuking Xorg when plugging in a USB device
Apr 30 22:40:45 <stintel> great
Apr 30 22:40:55 <stintel> clean image doesn't boot
Apr 30 22:41:09 <stintel> \nick yak-shaver
Apr 30 22:42:23 <stintel> I'm really getting tired of this shit. openwrt is getting into ubuntu territory wrt stability
Apr 30 22:46:31 <DonkeyHotei> the nature of the available hardware is a big factor in that
Apr 30 22:47:44 <stintel> it's not an excuse
Apr 30 23:50:52 <stintel>     brcm2708: rename target to bcm27xx
Apr 30 23:51:16 <stintel> seems this broke at least RPi3A 32bit images
Apr 30 23:51:43 <stintel> seriously people. do more testing before breaking the shit out of stuff
May 01 00:14:32 <russell--> stintel: did you ever get rtl-sdr to work with rpi's?
May 01 00:15:01 <stintel> russell--: 32bit works fine
May 01 00:15:05 <stintel> russell--: 64bit doesn't
May 01 00:15:14 <russell--> ah
May 01 00:15:27 <stintel> it's exactly this what I am currently trying to repair
May 01 00:17:15 <stintel> having both brcm*blah and cypress*blah firmware images doesn't help
May 01 00:17:40 <stintel> heck there aren't even any package conflicts defined
May 01 00:17:45 <owrt-snap-builds> build #290 of samsung/s5pv210 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/samsung%2Fs5pv210/builds/290
May 01 00:17:58 <stintel> you can select both, and then end up with a failure because of path conflicts
May 01 00:18:33 <stintel> I welcome the extra manpower, but some people really need to get their head straight
May 01 00:18:43 <stintel> breakage is everywhere
May 01 00:32:58 <gromero> hi. after one boots using initramfs, what's the correct way to get the remaining overlays loaded, luci, etc (from -squashfs-sysupgrade.bin I guess?)?
May 01 00:38:55 <gromero> actually what I mean is how to get luci and all the other tools loaded at that point after the boot I guess
May 01 00:41:49 <gromero> ah it's sysupgrade I was looking for. nm,
May 01 01:05:38 <russell--> stintel: a little more of the "thou shalt not break userspace" vibe would be generally appreciated. at least, when some breaking change is introduced/discovered, if the solution isn't immediately available, the breaking change maybe ought to be reverted.
May 01 01:06:39 <owrt-snap-builds> build #285 of ramips/mt7620 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7620/builds/285
May 01 01:16:42 <stintel> russell--: last 10 times I tried to work on something I got caught up yak shavin
May 01 01:16:55 <stintel> it's fucking frustrating
May 01 01:17:34 <stintel> but seems these days accepting contributions is preferred over properly reviewing them
May 01 01:22:48 <stintel> root@sdrpi3a:~# readsb --forward-mlat --mlat --net --help
May 01 01:22:48 <stintel> Segmentation fault
May 01 01:22:50 <stintel> sighj
May 01 01:23:00 <stintel> maybe I should just commit it and let someone else fix it
May 01 01:23:07 <stintel> seems to be the general flow these days
**** ENDING LOGGING AT Fri May 01 02:59:57 2020