**** BEGIN LOGGING AT Sat Apr 11 02:59:57 2020
Apr 11 03:08:40 <rr1231> building 19.02 with ath79 and failed at python-3.7.7?
Apr 11 03:09:03 <rr1231> on ubuntu 18.04, python3 default is 3.6
Apr 11 03:09:20 <rr1231> this is host-side python right? as make-menuconfig has no python selected
Apr 11 03:53:33 <rr1231> again make distclean fixed that python build issue
Apr 11 06:22:04 <musashino205> Hello. I'm working to add RTL8367S support to rtl8367b driver for Buffalo WSR-2533DHP2 and TP-Link TL-R600VPN. But I noticed the RTL8367C driver in mediatek target, is there a chance that my works will be merged if I send a patch?
Apr 11 06:30:39 <dengqf6> musashino205: that 8367c driver has too many unnecessary parts
Apr 11 06:31:05 <dengqf6> My Archer C5 v4 PR is yet to be merged
Apr 11 06:35:21 <musashino205> I see. WSR-2533DHP2 (MT7622B) uses HSGMII and TL-R600VPN uses SGMII. In my modificated rtl8367b driver, SGMII/HSGMII works now.
Apr 11 09:54:18 <mrkiko> gch981213: ping
Apr 11 10:05:23 * mangix grabs popcorn for this hz thread
Apr 11 10:05:36 <mrkiko> dengqf6: ping
Apr 11 11:12:57 <aparcar[m]> lynxis: I reworked the squashfs-tools-ng stuff and it seem to work fine, please check it out https://github.com/openwrt/openwrt/pull/2916
Apr 11 11:25:20 <dengqf6> mrkiko: try building kernel with "Optimize for size" option
Apr 11 11:25:58 <dengqf6> mrkiko: make menuconfig -> Global build settings -> Kernel build options -> the last option
Apr 11 12:32:38 <mrkiko> dengqf6: thanks man, doing it right now!! If this is the problem, it's a bad news for my device I guess
Apr 11 13:08:28 <karlp> aparcar[m]: IMO, your PR needs more of the _why_ not just the _what_ in it.
Apr 11 13:10:33 <karlp> russell--: I'm curous what you find, I know mpd would have been a choice for that ages ago, but no idea what's good now either.
Apr 11 13:19:17 <mrkiko> dengqf6: no luck :(
Apr 11 13:19:23 <mrkiko> of course I am sysupgradingwith -n option
Apr 11 13:20:55 <mrkiko> CONFIG_KERNEL_CC_OPTIMIZE_FOR_SIZE=y
Apr 11 14:02:33 <cotequeiroz> ping ldir
Apr 11 14:02:47 <russell--> karlp: there are lots of ancient suggestions on the internets ;-)
Apr 11 14:05:17 <dengqf6> mrkiko: Is the kernel size less than 2M?
Apr 11 14:06:52 <mrkiko> dengqf6: openwrt/bin/targets/ramips/mt7621/openwrt-ramips-mt7621-netgear_r6220-squashfs-kernel.bin ?
Apr 11 14:07:12 <mrkiko> dengqf6: 2057534 bytes
Apr 11 14:11:34 <dengqf6> mrkiko: have you tried a 3rd party bootloader?
Apr 11 14:12:04 <mrkiko> dengqf6: no... even because I don't know if the R6220 is supported by any of them.
Apr 11 14:13:20 <dengqf6> mrkiko: such as BREED
Apr 11 14:13:39 <mrkiko> dengqf6: BTW, in closed PR #2798 it seems even another guy is having problem with a D-Link device, DIR-860 B1 ?
Apr 11 14:15:02 <mrkiko> dengqf6: well, I knew about BREED but don't think it does support this board. I mean - don't think there is a build for it
Apr 11 14:15:32 <dengqf6> mrkiko: https://breed.hackpascal.net/breed-mt7621-r6220.bin
Apr 11 14:16:00 <mrkiko> Oh!!
Apr 11 14:16:42 <mrkiko> dengqf6: should I try?
Apr 11 14:20:07 <mrkiko> a little bit scared to flash, but telnet access would be really GREAT...
Apr 11 14:20:34 <Borromini> mrkiko: you're running into issues with master on mt7621 right?
Apr 11 14:30:35 <mrkiko> Borromini: yes
Apr 11 14:32:43 <Borromini> ok. i am in a similar boat. no serial like you :) i have a cable, but no pins :P
Apr 11 14:33:07 <mrkiko> ehehe :D I am blind, an solering serial ports isn't my strenght
Apr 11 14:33:09 <PaulFertser> mrkiko: I would recommend not flashing bootloader as there's no easy way to recover if flash goes bad. And also keep in mind BREED is proprietary.
Apr 11 14:33:36 <Borromini> mrkiko: oh, sorry :)
Apr 11 14:34:35 <mrkiko> Borromini: no need to be sorry :) BTW I guess you're italian like me
Apr 11 14:35:35 <Borromini> no belgian però parlo un pocchino d'italiano =)
Apr 11 14:35:43 <mrkiko> PaulFertser: infact I don't think I'll do, even tough I suspect dengqf6 has good reasons to think the problem maybe related to bootloader, and even tough access via telnet without ttl would be a good thing. But, I'm not brave enough right now.
Apr 11 14:35:56 <mrkiko> Borromini: ahah :D :D good!!
Apr 11 14:36:15 <Borromini> :D
Apr 11 14:36:21 <dengqf6> mrkiko: I didn't solder the serial port either
Apr 11 14:48:12 <mrkiko> dengqf6: do you have an R6220?
Apr 11 14:48:19 <dengqf6> No
Apr 11 14:48:41 <dengqf6> I have HC5962 and R3G
Apr 11 14:48:42 <mrkiko> dengqf6: ah, ok;
Apr 11 14:48:49 <dengqf6> Both are nand
Apr 11 14:49:05 <mrkiko> dengqf6: so you think it's bootloader because devices are very similar
Apr 11 14:49:19 <dengqf6> I use BREED on both
Apr 11 14:49:42 <mrkiko> to write it - did you use mtd-rw or what?
Apr 11 14:49:49 <ldir> cotequeiroz: pong
Apr 11 14:49:58 <mrkiko> dengqf6: still, you won't be able to see kernel boot failures, right?
Apr 11 14:51:57 <dengqf6> mrkiko: yes
Apr 11 15:17:41 <gch981213> jow: I think the missing vlan tag is a bug in this case.
Apr 11 15:19:29 <mrkiko> ok, boot successful
Apr 11 15:20:03 <gch981213> mrkiko: so you've flashed breed?
Apr 11 15:21:30 <gch981213> If replacing bootloader solved the problem I think the problem must be oversized kernel, as already suggested by dengqf6.
Apr 11 15:23:14 <mrkiko> gch981213: I can confirm, running 5.4.31 now
Apr 11 15:23:24 <mrkiko> my heart skipped some beats, but still...
Apr 11 15:24:36 <mrkiko> a little bit sad because I think this will stop a lot of people in installing uainsg openwrt on those devices, even tough they run quite well
Apr 11 15:24:52 <gch981213> maybe I should try enabling small_flash for ramips and see how much space this saves.
Apr 11 15:25:12 <gch981213> yeah. we can't just tell everyone to replace their bootloader.
Apr 11 15:27:29 <mrkiko> how do I stop breed from booting device? Ican talk to the shell
Apr 11 15:27:40 <mrkiko> but even abstatus doesn't interrupt the process as advertised
Apr 11 15:28:20 <mrkiko> I know, this isn't the rightp lace to ask
Apr 11 15:28:35 <gch981213> mrkiko: Holding down reset button until some led starts blinking
Apr 11 15:29:35 <PaulFertser> I would replace bootloader but not to a proprietary one. I'd rather recompile uboot with saner options.
Apr 11 15:30:03 <mrkiko> PaulFertser: yes, I agree
Apr 11 15:30:26 <mrkiko> gch981213: I can't see leds actually, I am blind; but pressing reset when breed started answering to ping didn't do the trick
Apr 11 15:31:27 <mrkiko> gch981213: ok, got it; should press reset *before* breed answers pings
Apr 11 15:42:17 <mrkiko> oh - I can't see my pCI wifi cards anymore, but who cares :)
Apr 11 15:43:15 <mrkiko> no, I am wrong, it works!
Apr 11 15:47:23 <mrkiko> well, mt7603 init fails, mt7612 works, apparently
Apr 11 15:47:33 <mrkiko> should I report my situation in the PR?
Apr 11 15:48:15 <dengqf6> mrkiko: try reboot
Apr 11 15:51:01 <mrkiko> seems to persistently fail - mt7603e 0000:02:00.0: Download request failed
Apr 11 15:51:08 <mrkiko> it's not a problem for me currently :D
Apr 11 15:51:30 <mrkiko> maybe I should let @paraka know
Apr 11 16:06:33 <mrkiko> gch981213: ... if this is a size limitation, we should consider how much it's widespread across devices. If it's very widespread, then ... yes, pretty inconvenient.
Apr 11 16:06:55 <mrkiko> gch981213: or maybe the need to build an intermediary bootloader arises
Apr 11 16:13:41 <blocktrron> https://bpaste.net/2L2A
Apr 11 16:13:51 <blocktrron> serial output from my r6220 using the latest snapshot
Apr 11 16:14:05 <blocktrron> rotanid: sorry for the delay here
Apr 11 16:15:14 <mrkiko> blocktrron: very grateful to you
Apr 11 16:16:46 <blocktrron> without having analyzed the cause - ramips has some kind of lzma-loader like ath79 does. So if this issue is bootloader related we might already have a solution at hand
Apr 11 16:17:04 <blocktrron> Given the fact the nand flash seems to be mapped in memory
Apr 11 16:17:40 <gch981213> blocktrron: Only NOR is mapped in memory.
Apr 11 16:17:59 <mrkiko> blocktrron: does this happen because the bootloader doesn't load the full kernel image and so some parts of the DTS are missing out?
Apr 11 16:18:59 <gch981213> nand is way more complicated to read from so almost all vendors chose to use a bootrom instead.
Apr 11 16:19:11 <Borromini> is r6220 NAND?
Apr 11 16:19:57 <mrkiko> Borromini: yes
Apr 11 16:20:03 <gch981213> I have no idea what's going on in that kernel log :(
Apr 11 16:20:35 <Borromini> mrkiko: ok.
Apr 11 16:21:09 <mrkiko> my impression is some DTS data is missing; but that log isn't clear to me as well. Still, blocktrron ... thank you very much for providing it.
Apr 11 16:21:46 <mrkiko> I am under the impression dengqf6 is right when he says it's a size issue.
Apr 11 16:26:04 <Borromini> mrkiko: yet optimize for size doesn't fix your issue right?
Apr 11 16:27:31 <Borromini> https://forum.openwrt.org/t/newest-snapshot-killed-my-edgerouterx/60214/7 < this is someone else with an MT7621 device, but at the moment it might just be a DSA issue because it looks like he kept configs
Apr 11 16:29:38 <mrkiko> Borromini: right; changing bootloader fixed it, and now it boots
Apr 11 16:30:12 <mrkiko> blocktrron: posted a panic on the r6220 with serial, see link above
Apr 11 16:32:25 <Borromini> mrkiko: ok, but that's not a trivial change (nor something you want to ask end users to do just because of an openwrt upgrade)
Apr 11 16:32:45 <Borromini> mrkiko: can you paste it again since i joined just after?
Apr 11 16:33:31 <mrkiko> Borromini: I totally agree with you... https://bpaste.net/2L2A
Apr 11 16:33:41 <Borromini> ty
Apr 11 16:34:36 <Borromini> well as we say in dutch... 'that chinese to me' :) way above my paygrade
Apr 11 16:42:32 <blocktrron> I've transfered the kernel from the sysupgrade image to 0x80600000, bootm from there and the device boots up just fine
Apr 11 16:42:47 <blocktrron> so yeah, looks like a bootlaoder issue indeed
Apr 11 16:50:03 <blocktrron> gch981213: snap, i assumed it would at leas give some output as "Copy from RAM" or something like that
Apr 11 16:57:57 <jmv200> -> kali linux <- build problem due to openwrt issue (!)
Apr 11 16:57:59 <jmv200> etting up firmware-b43legacy-installer (1:019-4) ...
Apr 11 16:58:00 <jmv200> downloads.openwrt.org (downloads.openwrt.org)|2a01:4f8:150:6449::2|:80... connected.
Apr 11 16:58:02 <jmv200> (downloads.openwrt.org)|2a01:4f8:150:6449::2|:443... connected.
Apr 11 16:58:04 <jmv200> connection.
Apr 11 17:01:21 <Borromini> blocktrron: does that sound similar to https://forum.openwrt.org/t/optimized-build-for-the-d-link-dir-860l/948/1083 ?
Apr 11 17:01:42 <blocktrron> Borromini: no, as decompression seems fine
Apr 11 17:01:51 <Borromini> xabolcs was in here a few days ago as well and his dir-860l boots with the initramfs image, but not with full sysupgrade/factory images
Apr 11 17:01:59 <blocktrron> but it might be a similar RC
Apr 11 17:02:19 <Borromini> RC?
Apr 11 17:03:10 <blocktrron> root cause
Apr 11 17:03:41 <blocktrron> sadly it's the only mt7621 i have access to apart from a nanoHD i don't want to open
Apr 11 17:04:09 <Borromini> oh. ok
Apr 11 17:07:47 <Borromini> i thought 'maybe it's a similar issue to the inline code affecting ath79', so i tried with gcc 8.4 with the revert & 9.3.0, but same behaviour
Apr 11 17:09:40 <ynezz> FYI Repository mirroring on openwrt/project/fstools has been paused due to too many failures. The last failure was: The default branch (master) has diverged from its upstream counterpart and could not be updated automatically.
Apr 11 17:18:24 <blocktrron> gch981213: when the NAND flash isn't memory-mapped, why does "bootm bfe00000" load the kernel on my unit?
Apr 11 17:19:53 <blocktrron> or does the bootloader do it's own magic here?
Apr 11 18:46:50 <cotequeiroz> ldir: I just wanted to comment about c39d015 (.gitignore).  The files you found were leftovers from previous config version.  You may just delete them, but leaving them in .gitignore won't hurt too much.
Apr 11 18:52:28 <ldir> cotequeiroz: Ah! Ooops.  OK.  I'll revert that then
Apr 11 18:55:20 <ldir> done
Apr 11 19:03:13 <jow> ynezz: again ?
Apr 11 20:37:06 <karlp> it's agile ;)
Apr 11 20:41:56 <mrkiko> blocktrron: dengqf6: updating PR comment
Apr 11 20:45:05 <aparcar[m]> ynezz dangole there seem to be some stuff happening around apk btw https://gitlab.alpinelinux.org/alpine/apk-tools/issues/10684
Apr 11 20:45:21 <aparcar[m]> karlp: thank you I'll update the commit messages for the squashfs PR
Apr 11 20:48:43 <jow> hm, trying to parse https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html
Apr 11 20:49:17 <jow> tbh this looks equally messy as swconfig
Apr 11 20:49:25 <jow> instead of swconfig you now have bridge
Apr 11 20:49:28 <jow> but still
Apr 11 20:49:41 <jow>  - you need to know your hardware capabilities in advance to guess the right config approach
Apr 11 20:49:53 <jow>  - you need to know the hardware topology in advance to know the right config
Apr 11 20:51:40 <jow> and you still need to configure vlans in two places
Apr 11 20:51:58 <jow> once on the "cpu port" (which you need to guess / know)
Apr 11 20:52:12 <jow> and once per switch port, but using a different command
Apr 11 20:52:28 <aparcar[m]> device tree doesn't fix that?
Apr 11 20:52:50 <jow> looks to me as if we could simply keep the same uci config as for swconfig and translate the vlan specs to bridge commands internally
Apr 11 20:53:51 <jow> but still confusing as hell
Apr 11 20:54:28 <jow> so that "bridge vlan add dev lanX vid Y pvid untagged" stuff ends up on eth0.Y
Apr 11 20:55:11 <jow> and why is the port netdev itself put into the bridge but the per-vlan cpu port?
Apr 11 20:55:45 <jow> does that mean that if I have a vlan trunk of vid 10 + 20 on say lan1, I need to put lan1, eth0.10 *and* eth0.20 into a bridge?
Apr 11 20:56:33 <jow> ah no, nvm
Apr 11 21:34:40 <aparcar[m]> jow: please have a look at the JSON patches, without them available upstream my current upgrade server implementation can't be initialized
Apr 11 21:35:27 <jow> sigh... yes
Apr 11 21:35:39 <jow> is this final then?
Apr 11 21:35:59 <jow> or wil lthis need more fixes a day later?
Apr 11 21:37:24 <jow> hm, no can't / won't merge it
Apr 11 21:37:39 <jow> the same build setup is shared for master, 19.07 and 18.06
Apr 11 21:37:43 <aparcar[m]> jow: depends a bit on how the buildbot turns out. I have no Buildbot running on my own
Apr 11 21:37:46 <jow> merging this will break the two latter ones
Apr 11 21:38:31 <aparcar[m]> okay that makes sense. Adding a if condtition to check the build version should fix it right?
Apr 11 21:38:39 <jow> I also don't like the fact that we keep introducing new buildroot make targets. Can't this json stuff be called as part of the image building?
Apr 11 21:38:46 <aparcar[m]> as all future releases would ideally include that step
Apr 11 21:39:47 <jow> how is it supposed to work for people building openwrt themselves? Do they have to explicitely call "make json_overview_image_info" as well?
Apr 11 21:40:13 <jow> or did you hook it into make world?
Apr 11 21:40:27 <aparcar[m]> no it happens when running prepare
Apr 11 21:40:41 <jow> make prereq ?
Apr 11 21:40:51 <aparcar[m]> and prepare is a dependency of world
Apr 11 21:40:54 <aparcar[m]> however the build bot runs the single steps instead of calling prepare
Apr 11 21:42:15 <aparcar[m]> oh sorry it's hooked into world not prepare
Apr 11 21:42:32 <jow> isn't it prone to race conditions?
Apr 11 21:43:03 <aparcar[m]> sorry I'm missing how
Apr 11 21:43:43 <jow> make -j32 world
Apr 11 21:44:04 <jow> will happily execute the other steps and json_overview_image_info concurrently unless json_overview_image_info depends on the image build artifacts somehow
Apr 11 21:45:56 <aparcar[m]> aren't the steps called serially within the world target and also the buildbot runs the steps one after another?
Apr 11 21:46:16 <jow> ah yes, just notice
Apr 11 21:48:47 <jow> gah and why is menuconfig terminaing on recursive deps now?
Apr 11 21:49:31 <aparcar[m]> there were some recent patches, however I think not JSON related duck
Apr 11 21:51:45 <jow> this is bs
Apr 11 21:52:05 <aparcar[m]> bs?
Apr 11 21:52:18 <jow> I'd rather not say
Apr 11 21:52:21 <jow> http://builds.openwrt.org/master/packages/one_line_per_build
Apr 11 21:53:41 <aparcar[m]> jow: think think there is some talking on the ML regarding this trouble
Apr 11 21:54:13 <aparcar[m]> btw are you still interested in upgrading the buildbot to a newer version?
Apr 11 21:54:33 <jow> it have everything ready locally
Apr 11 21:55:02 <jow> but stuff like this wonderful new kconfig update keep eating the little precious time I have to work on actual things
Apr 11 21:55:27 <jow> out of the five past hours, I spent over four fighting with various fallout in master
Apr 11 21:55:38 <jow> which is ... furstrating
Apr 11 21:56:01 <jow> and now I learn that package building has been broken for days
Apr 11 21:57:57 * aparcar[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/UHEBxyloBIbxLHXxBmQNWRNw >
Apr 11 21:58:35 <aparcar[m]> maybe this feature from dcf3e63a35 introduces the trouble
Apr 11 22:04:14 <champtar> Hi all, before I waste too much time, anyone know how to bridge 2 DSA port (lan4/lan5) but not have hardware offload / see the traffic in tcpdump for exemple
Apr 11 22:07:41 <aparcar[m]> jow: do you have local buildbot update somewhere online?
Apr 11 22:07:56 <aparcar[m]> the code, not a live runnin system
Apr 11 22:18:09 <jow> aparcar[m]: https://git.openwrt.org/?p=buildbot.git;a=shortlog;h=refs/heads/buildbot-2.4.1
Apr 11 22:25:51 <aparcar[m]> jow: arigato
Apr 11 22:34:26 <aparcar[m]> jow: I patched the buildbot some time ago via https://github.com/buildbot/buildbot/pull/5065 so your sed patching could be simplified https://git.openwrt.org/?p=buildbot.git;a=blob;f=docker/buildslave/files/start.sh;h=56f878d6b80bc4c4cc6bed74e324b639ac4ede71;hb=fcdf1751d014fd6c612bdecb6c79858eff82ab89#l21
Apr 11 22:45:06 <aparcar[m]> jow: seems like they only added it in buildbot 2.6.0, any reasons not to upgrade to 2.6 (or even 2.7 which is most recent)
Apr 11 22:50:13 <aparcar[m]> jow: what should I do now about the buildbot step?
Apr 11 22:56:47 <f00b4r0> shameless plug: if buildbot gets updated to something newer I'd be quite happy to revert https://git.openwrt.org/?p=buildbot.git;a=commitdiff;h=1e1a326074018542c4a6f14ffe12984fa9c8a192, which in turn would enable me to resume both slashdirt buildbots :)
Apr 11 22:57:12 <f00b4r0> jow: ^ (also don't forget the one-liner i sent a couple months ago :)
**** ENDING LOGGING AT Sun Apr 12 03:00:14 2020