**** BEGIN LOGGING AT Wed Jun 17 02:59:57 2020
Jun 17 05:54:05 <Grommish> Can anyone explain what the rootfs_data is actually for, and how I can use it to my advantage?
Jun 17 06:25:29 <ynezz> Grommish: https://openwrt.org/docs/techref/flash.layout
Jun 17 06:25:50 <ynezz> root is mostly read-only, rootfs_data is writable overlay
Jun 17 06:33:27 <Grommish> Here's my issue.. I've got a ELF BIN that gets loaded into RAM at boot
Jun 17 06:33:38 <Grommish> With 800MB of Storage on a MMC ext3 partition
Jun 17 06:34:10 <Grommish> I'm trying to make use of it without just copying everything from the BIN over.. makes upgrading a nightmare
Jun 17 06:34:43 <Grommish> So I was hoping the rootfs_data would act act as the storage redirect for user/system changes
Jun 17 06:35:01 <Grommish> if that makes any sense..
Jun 17 06:36:57 <ynezz> so you're booting 800MB initramfs?
Jun 17 06:37:44 <Grommish> 110MB give or take fully loaded
Jun 17 06:37:49 <Grommish> Base image is 17Mb
Jun 17 06:37:54 <Grommish> And device RAM is 1GB
Jun 17 06:38:29 <Grommish> It was a one-off network security device that died a quick death, leaving no support.
Jun 17 06:40:03 <ynezz> you would probably need to mount that rootfs_data overlay manually, hacking around the init scripts
Jun 17 06:40:11 <Grommish> BIN gets loaded into RAM and then boots like a Live disc on Linux.. Everything is RAM resident.
Jun 17 06:40:18 <Grommish> Oh, that isn't an issue, i have an custom init anyway
Jun 17 06:40:29 <ynezz> AFAIK this use case is not supported out of the box
Jun 17 06:40:49 <Grommish> This device isn't supported at all, so I'm use to it.. one sec
Jun 17 06:41:12 <ynezz> maybe some of this is in procd, so it might need a "little bit" of a C as well
Jun 17 06:41:41 <Grommish> https://forum.openwrt.org/t/designing-openwrt-device-from-the-nearly-ground-up/66642/7
Jun 17 06:41:58 <Grommish> If that helps.. I had to hand-patch in the Ethernet drivers, so if I can find source code, I can change it
Jun 17 06:42:38 <Grommish> It doesn't have a vmlinux file, the kernel is built into the BIN
Jun 17 06:43:08 <Grommish> Previously, i was using switch_root() from init to jump to the mmc blk
Jun 17 06:43:21 <Grommish> after copying the RAM-resident files to the device
Jun 17 06:44:01 <Grommish> But that leads to all kinds of issues with upgrades.. because I have to replace the entire image and then reboot.. unless there is another wya to do it.. this is a reference board, so it is completely open
Jun 17 06:46:37 <Grommish> I do compile from master.  I'm not using an imagebuilder
Jun 17 08:19:43 <enyc> Channel topic needs updahing for 19.07.3   please  <<<<<< chanops!
Jun 17 08:19:52 <enyc> I'm happy to help chanop etc....
Jun 17 08:26:56 <jow> wigyori: ^
Jun 17 08:38:27 <ldir> The obvious solution is to chanop++
Jun 17 08:38:51 <ldir> or even chanop+=2
Jun 17 08:54:57 <ynezz> IIRC chanop is statis
Jun 17 08:55:03 <ynezz> s/statis/static/ :)
Jun 17 08:57:55 <ldir> more const I think :)
Jun 17 08:58:05 <ynezz> ah, right
Jun 17 08:58:17 <ynezz> I can't even make proper jokes
Jun 17 08:58:36 <ldir> lol
Jun 17 08:59:25 <ldir> it could be static - it's certainly out of my scope
Jun 17 09:08:18 <aparcar[m]> How is the introduction of DSA linked to dropping SUPPORTED_DEVICES? I'm looking at df6f3090 mvebu: rename Linksys devices based on their common names
Jun 17 09:08:48 <aparcar[m]> adrianschmutzler: -^
Jun 17 09:09:56 <ynezz> you're the author of that patch, arent you? :p
Jun 17 09:10:01 <jow> aparcar[m]: a hack to prevent clean sysupgrade
Jun 17 09:10:09 <jow> to not raise user expectations about config comaptibility
Jun 17 09:10:33 <aparcar[m]> jow: but adding the new name would be okay wouldn't it?
Jun 17 09:10:50 <aparcar[m]> so instead of linksys,rango then linksys,wrt3200acm
Jun 17 09:10:58 <stintel> what about devices that are supported in ar71xx but not yet in ath79? are we going to release 20.* without ar71xx builds while devices are not supported in ath79?
Jun 17 09:11:25 <aparcar[m]> I was happy to eventually a mapping between running device knowledge and OpenWrt build system profiles, however this was false hope
Jun 17 09:11:41 <jow> stintel: undecided
Jun 17 09:11:47 <aparcar[m]> ynezz: It was modified by adrianschmutzler
Jun 17 09:11:48 <jow> stintel: I wouldn't
Jun 17 09:12:24 <jow> stintel: dropping a large chunk of ar71xx supported devices entirely while also breaking a number of other boards with DSA will likely lead to a perception of 20.x being a very bad and ill executed release
Jun 17 09:12:31 <ynezz> aparcar[m]: https://git.openwrt.org/4dc6b453e8d7ba12d4e80c68e18a4fdeffcd4c61
Jun 17 09:12:49 <ynezz> but it's still wip
Jun 17 09:12:52 <stintel> I was considering the following: start by removing all devices that are supported by ath79 from the ar71xx target, so we can at least see what is left to port
Jun 17 09:13:00 <jow> yep, that totally makes sense
Jun 17 09:13:40 <aparcar[m]> ynezz: I was about to propose pretty much the same patch however with linksys,wrt3200acm as first supported device. any reason you don't add that?
Jun 17 09:14:05 <ynezz> isn't it default?
Jun 17 09:14:40 <adrianschmutzler> The idea was to prevent a non-working config when users update from swconfig to DSA without thinking
Jun 17 09:14:58 <adrianschmutzler> As they might not be aware that something changed in an incompatible way in master
Jun 17 09:15:43 <aparcar[m]> the DT changed and therefore an old wrt3200 would identify itself as rango, therefore not work with the new image even if linksys,wrt3200acm is in SUPPORTED_DEVICES, not?
Jun 17 09:15:47 <adrianschmutzler> so dropping SUPPORTED_DEVICES was meant to have a least some point where the user has to think
Jun 17 09:15:58 <ynezz> but suggesting `sysupgrade -F` is in my eyes much worse
Jun 17 09:16:11 <Namidairo> were transition scripts still off the table as too complex
Jun 17 09:16:20 <ynezz> what about rather booting into failsafe on such devices?
Jun 17 09:16:36 <adrianschmutzler> I don't like removing the supported devices either
Jun 17 09:16:47 <ynezz> or backing up the network config and providing default working network in DSA?
Jun 17 09:16:51 <adrianschmutzler> that's why I try to come up with this sysupgrade compatibility thing
Jun 17 09:17:57 <adrianschmutzler> ynezz: The latter would be one option, but it's already close to the migration script we discussed yesterday again
Jun 17 09:18:09 <aparcar[m]> is it possible to detect if the swconfig != default and if so block the sysupgrade with a warning?
Jun 17 09:18:10 <ynezz> aparcar[m]: http://sprunge.us/gHWCVR
Jun 17 09:18:18 <aparcar[m]> so regular user not modifying anything can just upgrade
Jun 17 09:18:25 <jow> aparcar[m]: since rmilecki's sysupgrade checks it should be possible
Jun 17 09:18:51 <jow> we can for exmaple signal image compatibility but disallow config retaining at the same time
Jun 17 09:18:58 <adrianschmutzler> aparcar: one could also just make an uci-defaults with a list of devices and then check for a switch_vlan option
Jun 17 09:19:13 <aparcar[m]> ynezz: amazing that's what I was hoping for
Jun 17 09:19:30 <adrianschmutzler> jow: that's close to what I tried in my patch
Jun 17 09:21:25 <rmilecki> aparcar[m]: just have to simply call "notify_firmware_no_backup" from platform_check_image() if sysupgrade with keeping config should not be possible
Jun 17 09:21:28 <aparcar[m]> ynezz: Okay I wan't aware of this magic SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
Jun 17 09:22:19 <rmilecki> aparcar[m]: e.g. https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/bcm53xx/base-files/lib/upgrade/platform.sh;h=40b2ef67be5b9c1f2a0cfbdf1717f0747d148e75;hb=HEAD#l177
Jun 17 09:22:51 <rmilecki> aparcar[m]: we force users to *not* keep config when installing vendor firmware
Jun 17 09:23:22 <rmilecki> ("lxlold" in bcm53xx is format used by vendor only)
Jun 17 09:27:02 <aparcar[m]> I have no clue about DSA, can't it be postponed until 20.12 when there are stable migration scripts?
Jun 17 09:28:44 <ynezz> with 4.19 kernel, yes :)
Jun 17 09:29:22 <aparcar[m]> swconfig is removed in 5.4?
Jun 17 09:29:51 <ynezz> rather some targets switched to DSA
Jun 17 09:30:06 <ynezz> IIRC some will remain using swconfig
Jun 17 09:30:29 <aparcar[m]> so swconfig is something OpenWrt came up with and DSA is the kernel way?
Jun 17 09:32:40 <jow> aparcar[m]: yes
Jun 17 09:36:16 <aparcar[m]> something entirely different, would it make sense to have libubox, uci etc as debian libs? My current build setup would involve a package clean/compile via the build system every time.
Jun 17 09:36:36 <aparcar[m]> Or any advise on a correct dev setup?
Jun 17 09:37:01 <ynezz> the one which works for you ;)
Jun 17 09:37:56 <aparcar[m]> ynezz: my knowledge in this area is to limited to even know what can be considered as working
Jun 17 09:39:12 <aparcar[m]> coming from python the run cycle is from one keystroke now about 4 minutes of git amending the packages feed, compile via build system, copying package to a vm, install it, run it.
Jun 17 09:40:49 <ynezz> if you need faster feedback loop you need to optimize out some steps
Jun 17 09:41:12 <ynezz> you don't need package for example in order to test some changes
Jun 17 09:41:19 <aparcar[m]> this is why I ask e.g. you
Jun 17 09:41:23 <ynezz> you dont even need VM to run it
Jun 17 09:42:36 <ynezz> most of the stuff runs fine natively
Jun 17 09:42:45 <aparcar[m]> nice I'll check that
Jun 17 09:42:58 <ynezz> I'm building with -D CMAKE_PREFIX_PATH=/opt/devel/openwrt/testing -D CMAKE_INSTALL_PREFIX=/opt/devel/openwrt/testing and then using stuff in those dirs
Jun 17 09:43:05 <aparcar[m]> I got something using ubus but that likely runs native as well..
Jun 17 09:43:31 <ynezz> http://sprunge.us/iIPBAv
Jun 17 09:43:47 <ynezz> source /opt/devel/openwrt/testing/environment
Jun 17 09:44:26 <aparcar[m]> nice thank you very much
Jun 17 09:45:06 <aparcar[m]> seems like lynxis also ported some packages to debian, but I'll test your approach
Jun 17 09:46:25 <aparcar[m]> good night everyone, thanks for the insights in dsa & building
Jun 17 09:47:16 <ynezz> then you can have `cmake/openwrt-toolchain-imx6.cmake` http://sprunge.us/GHA3yw and do `-D CMAKE_TOOLCHAIN_FILE=cmake/openwrt-toolchain-imx6.cmake`
Jun 17 09:48:20 <ynezz> custom `make upload` target http://sprunge.us/nVfCn2 etc.
Jun 17 09:49:52 <Ivan_83> why so hard commit simple patch to owrt!?
Jun 17 09:54:04 <jow> because your patch is not simple and needs to be regression tested on OS X and Linux first (assuming you mean https://github.com/openwrt/openwrt/pull/3110)
Jun 17 09:54:48 <jow> it also sneaks changes into json-c without explaination
Jun 17 09:54:54 <Ivan_83> jow: I mean https://github.com/openwrt/openwrt/pull/2352
Jun 17 09:55:21 <Ivan_83> and probably https://github.com/openwrt/packages/pull/12516
Jun 17 09:55:59 <Ivan_83> 2352 - almost 1 year
Jun 17 09:56:20 <Ivan_83> simple shell script changes
Jun 17 09:56:27 <adrianschmutzler> #2352 is not simple, and it does multiple things at once. When I asked to split it up, you said no IIRC.
Jun 17 09:56:51 <adrianschmutzler> or somebody said no, don't know whether it was you
Jun 17 09:57:10 <Ivan_83> I have no idea how to split it and why
Jun 17 09:57:55 <jow> it looks fine to me
Jun 17 09:58:07 <adrianschmutzler> Despite, it has no tested-by and I don't remember how it went with xabolcs
Jun 17 09:58:14 <jow> though I had to read the code to figure out what it was supposed to do
Jun 17 09:58:44 <Ivan_83> it already tested by some user
Jun 17 09:58:46 <adrianschmutzler> jow: don't want to stop you if you want to merge, of course
Jun 17 09:59:30 <jow> I was going through the backlog
Jun 17 10:00:01 <jow> the very first PR I looked at yesterday (openvpn hotplug) already took up my entire time though and proved to completely break my setup, it was simple shell scriupt changes too
Jun 17 10:00:57 <jow> 2352 looks sane though, the only potential issue I see is the newly introduced manufacturer lookup that now prevents the proto setup when failing while the previous logic continued
Jun 17 10:01:40 <jow> ah nvm, missed some context
Jun 17 10:04:01 <Ivan_83> as I remember this pr saves some time after modem replug and prevent some rrors on unplug
Jun 17 10:04:05 <dwmw2_gone> Do we have an "install image" for x86 and other platforms where we can insert removable media, but want to install to the internal storage?
Jun 17 10:04:19 <dwmw2_gone> Banana Pi R2 is the same; we can boot from SD card, and then install to the internal eMMC.
Jun 17 10:04:43 <dwmw2_gone> I'm looking at abusing sysupgrade (since U-Boot can't see the internal eMMC when booted from SD, even though Linux can)
Jun 17 10:04:53 <dwmw2_gone> first thought was an option in the U-Boot boot menu
Jun 17 10:37:08 <Borromini> dwmw2_gone: isn't that as easy as wget'ing the image when booted from your usb stick e.g. and dd'ing the x86 image to internal storage then?
Jun 17 10:37:42 <dwmw2_gone> for x86 yes. For Banana Pi we also need to set up the mmcblk0boot0 partition
Jun 17 10:37:48 <dwmw2_gone> sysupgrade can already handle that.
Jun 17 10:38:22 <dwmw2_gone> I could provide a script which does it when you've fully booted from SD card. Ideally using the contents of the SD card instead of needing to configure and bring up the network.
Jun 17 10:39:18 <dwmw2_gone> echo "root=/dev/mmcblk0p3" > /tmp/fake-cmdline ; mount -oremount /tmp/fake-cmdline /proc/cmdline ; sysupgrade /dev/mmcblk1 :)
Jun 17 10:39:25 <dwmw2_gone> Wonder how that'd work.
Jun 17 10:39:56 <dwmw2_gone> trick it into thinking it booted from the internal mmc, then sysupgrade from the image on the sd card.
Jun 17 10:40:11 <dwmw2_gone> I suppose it'd have no metadata appended
Jun 17 11:05:09 <dwmw2_gone> hm
Jun 17 11:05:19 <dwmw2_gone> the / partition isn't being unmounted in sysupgrade
Jun 17 12:13:41 <dwmw2_gone> oh, nothing does the 'losetup -d' to kill the loop0 that's using the other part of the root partition
Jun 17 13:40:46 <xx_ns> hi there!
Jun 17 13:41:00 <xx_ns> first time attempting to port openwrt to a new device
Jun 17 13:41:10 <xx_ns> this one specifically: https://openwrt.org/toh/zte/zte_zxhn_h368n
Jun 17 13:41:15 <PaulFertser> xx_ns: I hope it goes smooth for you
Jun 17 13:41:37 <dwmw2> hm
Jun 17 13:41:46 <dwmw2> fstools' mount_root 'stop' doesn't actually do anything
Jun 17 13:42:00 <dwmw2> in particular it doesn't unsetup the loop device, and doesn't release the root partition
Jun 17 13:42:02 <xx_ns> any tips on where to get started or what to document? currently figuring out GPIO, but idunno if there's bigger, more important fish to fry
Jun 17 13:42:04 <dwmw2> I need to 'losetup -d'
Jun 17 13:44:36 <adrianschmutzler> xx_ns: might be helpful to document MAC addresses while you still have vendor firmware, but that's not really something terribly important that you would want to do first
Jun 17 13:45:42 <adrianschmutzler> bootlog and partition seem to be already known in the wiki ...
Jun 17 13:45:51 <xx_ns> i just posted those :)
Jun 17 13:46:47 <xx_ns> something to note - i have a variant of the device branded for a different ISP, and a lot of the things that were already in the wiki don't apply for this one
Jun 17 13:47:28 <xx_ns> for example, serial output works out of the box (drops into a shell, username root password root), and the CFE web server isn't password protected
Jun 17 13:48:42 <PaulFertser> xx_ns: I'd try to get something bootable over initramfs first
Jun 17 13:48:51 <PaulFertser> xx_ns: then I'd make wired ethernet work, and wireless.
Jun 17 13:49:10 <xx_ns> sounds good
Jun 17 13:49:32 <PaulFertser> xx_ns: look at commits adding support for devices based on same/similar SoC to get a generic idea of what it usually takes
Jun 17 13:49:43 <xx_ns> i'll do that, cheers
Jun 17 13:50:48 <xx_ns> i apologise in advance for all of the really stupid questions i'll start asking
Jun 17 14:28:21 <enyc> Hrrm -- is there likely to be an 18.06.9 at all?
Jun 17 14:29:23 <Borromini> enyc: i thought so, but it doesn't look like it. you might try digging through the mailing list archives of the past few months
Jun 17 14:33:27 <enyc> Borromini: hrrm there are some 18.06 patches going on, and buildbot still building 18.06'es ...
Jun 17 14:34:39 <Borromini> sure
Jun 17 14:35:55 <ldir> As much as anything I suspect it's 'personpower'/'personhours' availability on a volunteer/unpaid project.
Jun 17 14:45:29 <jow> I think an 18.06.9 will only happen if a major flaw is found before 20.x is released
Jun 17 14:45:35 <jow> there is none planned atm
Jun 17 14:49:20 <zorun> err, there is this libubox regression (same as in 19.07.2) that I sent a pach abou
Jun 17 14:49:39 <zorun> it should definitely be fixed
Jun 17 14:49:46 <zorun> https://bugs.openwrt.org/index.php?do=details&task_id=3177
Jun 17 14:50:22 <jow> zorun: ah, interesting
Jun 17 14:50:31 <jow> that I explains all the LuCI tickets and how resetting the config solved it
Jun 17 14:50:35 <zorun> yes :)
Jun 17 14:50:35 <jow> never understood that problem
Jun 17 14:50:51 <zorun> this is what I was debugging because it has annoyed many of our users
Jun 17 14:51:26 <zorun> turns out to be the same issue rmilecki had been debugging for 19.07.2
Jun 17 14:51:28 <jow> the libubox are clean cherry-picks?
Jun 17 14:51:45 <zorun> yes, but I would like some double-check that these were the right commits to cherry-pick
Jun 17 14:51:58 <jow> iirc we already started an openwrt-18.06 branch in libubox, so I'll pick these fixes there and we simply bump the package in 18.06
Jun 17 14:52:16 <zorun> ah ok, I saw that previous fixes were included as patches
Jun 17 14:52:39 <zorun> (it's done differently in 19.07)
Jun 17 14:52:47 <dwmw2> haha. I broke overlay. But that's OK because I'm never rebooting only sysupgrading
Jun 17 14:52:53 <dwmw2> so using tmpfs is just fine
Jun 17 14:53:35 <jow> dwmw2: that earlier losetup -d remark of yours... we should investigate this. Since x86 also uses f2fs/ext4 on top of an loopback mount it might be a problem there too
Jun 17 14:53:46 <dwmw2> I assume it is
Jun 17 14:53:50 <jow> sounds like somethjing we should stick into sysupgrades platform.sh
Jun 17 14:53:56 <dwmw2> experiemnting with LO_FLAGS_AUTOCLEAR
Jun 17 14:54:03 <dwmw2> but that breaks if you immediately close the fd afterwards :)
Jun 17 14:54:08 <dwmw2> so I'm just *leaking* that fd for now
Jun 17 14:54:24 <dwmw2> it'll go to autoclear by the time /sbin/mount_root exits, by which time it'll be mounted.
Jun 17 14:54:33 <dwmw2> if that's working I'll look at a nicer way to explicitly close the fd
Jun 17 14:54:50 <dwmw2> that way we don't need to incluide losetup at all.
Jun 17 14:55:43 <zorun> jow: regarding 18.06.9, I would like to learn how to make a release (and maybe combine that with finally setting up builders on the openstack cluster), is it possible and would you have time at some point to help?
Jun 17 14:56:09 <dwmw2> jow: you get away with if it sysupgrade doesn't *change* the partitions. So I only found it when torture-testing the bpir2 sysupgradfe
Jun 17 14:56:16 <Ivan_83> jow: any progress with #2352 ?
Jun 17 14:56:28 <zorun> or should I first ask to become a developer?
Jun 17 14:56:43 <jow> zorun: if at all then only on mondays, fridays or weekend
Jun 17 14:56:49 <jow> (helping, that is :P)
Jun 17 14:57:02 <zorun> ok :)
Jun 17 14:57:06 * zorun looks at the current date
Jun 17 14:57:13 <xx_ns> pretty cool! I compiled the default bcm963268bu-p300 platform and it booted up fine! very exciting
Jun 17 14:57:28 <jow> Ivan_83: sorry, was afk until I reappaeared here, so no
Jun 17 15:04:08 <dwmw2> jow: http://david.woodhou.se/010-autoclear.patch fixes it the ugly way.
Jun 17 15:07:59 <Ivan_83> :(
Jun 17 16:15:09 <xx_ns> I see from the wiki that the previous person to work on this device (five years ago) was called rqn - does this ring a bell to anyone? Would like to get in contact with them
Jun 17 16:16:06 <xx_ns> quick google shows that that's the only time that username's been active - shame
Jun 17 16:59:04 <dangole> jow: it'd be great to have that uclient-fetch --post-file= option also in 19.07, it's mostly needed for LibreMesh shared state running on small devices (4MB flash) without luci-lib-httpclient, ie. they will anyway only ever run 19.07.x...
Jun 17 17:08:45 <adrianschmutzler> Anybody has an opinion what to do with kernel 4.19 support in the long run? Only 5.4 and 4.14 is released, and soon all targets except cns3xxx will be on 5.4 or 4.14 either.
Jun 17 17:09:26 <adrianschmutzler> I just wondered whether it makes sense to maintain it with respect to bumping kernel and updating config after the last targets have been bumped ...
Jun 17 19:00:07 <xx_ns> so everything's booting and cool, but I'm sort of at a loss for what I should be doing next to get networking to work. The wiki page lists RTL8367RB as the switch, however even after loading the rtl8367b kmod, swconfig only lists switch0 - eth0. As far as I can see, that's a broadcom thing? But I'm not really sure what to do with this information
Jun 17 19:04:48 <PaulFertser> xx_ns: switch is likely controlled over MDIO
Jun 17 19:05:13 <PaulFertser> xx_ns: and you need appropriate entry in the DTS so that the driver can try binding to it.
Jun 17 19:08:15 <xx_ns> PaulFertser: ah, fair enough
Jun 17 19:11:27 <PaulFertser> xx_ns: the same switch is used by nb6-ser-r0.dts probably?
Jun 17 19:15:04 <jow> dangole: just push the change
Jun 17 19:16:50 <PaulFertser> xx_ns: looks like it's controlled over SMI that looks a lot like I2C, and the driver is bitbanging it, so you need to specify correct GPIOs.
Jun 17 19:17:50 <xx_ns> PaulFertser: ok, thanks for the info! For reference, if you don't mind me asking, how exactly did you deduce this? :) Seems like magic to me
Jun 17 19:19:55 * ldir sniggers at "Dissent is best expressed in 'diff -up' form."
Jun 17 19:19:58 <PaulFertser> xx_ns: I did 'git grep rtl8367' in the source tree, looked at DTS files that mention it, then took a look inside rtl8366_smi.c
Jun 17 19:22:17 <PaulFertser> xx_ns: if there's a functional mdio driver then it should be able to work via it too.
Jun 17 19:24:26 <PaulFertser> xx_ns: I think it was a mistake of ar7242_tplink_tl-wr2543-v1.dts author to add both and only mdio driver is used there.
Jun 17 20:06:15 <owrt-1907-builds> build #181 of malta/be is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/malta%2Fbe/builds/181  blamelist: Daniel Golle <daniel@makrotopia.org>
Jun 17 20:06:53 <owrt-1907-builds> build #179 of mpc85xx/generic is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mpc85xx%2Fgeneric/builds/179  blamelist: Daniel Golle <daniel@makrotopia.org>
Jun 17 20:06:58 <owrt-1907-builds> build #180 of octeontx/generic is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/octeontx%2Fgeneric/builds/180  blamelist: Daniel Golle <daniel@makrotopia.org>
Jun 17 20:08:20 <owrt-1907-builds> build #176 of layerscape/armv8_64b is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/layerscape%2Farmv8_64b/builds/176  blamelist: Daniel Golle <daniel@makrotopia.org>
Jun 17 20:45:28 <owrt-1907-builds> build #179 of ramips/rt3883 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt3883/builds/179  blamelist: Daniel Golle <daniel@makrotopia.org>
Jun 17 20:45:34 <owrt-1907-builds> build #177 of mvebu/cortexa72 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa72/builds/177  blamelist: Daniel Golle <daniel@makrotopia.org>
Jun 17 20:46:27 <owrt-1907-builds> build #178 of ar71xx/mikrotik is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fmikrotik/builds/178  blamelist: Daniel Golle <daniel@makrotopia.org>
Jun 17 20:46:41 <owrt-1907-builds> build #175 of armvirt/32 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/armvirt%2F32/builds/175  blamelist: Daniel Golle <daniel@makrotopia.org>
Jun 17 20:49:57 <jow_> Ivan_83: ping
Jun 17 20:50:29 <jow_> Ivan_83: I am looking at #2352 now and have some questions... the commit message needs to be a bit clearer but thats fine, I'll take care of that
Jun 17 20:50:51 <jow_> Ivan_83: but I need to understand how exectly the change is fixing hotplug / device reconnect
Jun 17 20:51:15 <jow_> - a) is it simply preventing the interface from attempting to start when the control device is invalid?
Jun 17 20:51:31 <jow_> - b) is one of the manufacturer read operations somehow triggering a device reconnect?
Jun 17 20:51:42 <Ivan_83> jow_: pong
Jun 17 20:52:27 <jow_> I suppose the key is the [ -n "$device" ] and [ -e "$device" ] checks
Jun 17 20:53:49 <Ivan_83> jow_: after connect some times modem does not return manufacturer and script stuck for 10-30 sec
Jun 17 20:54:33 <Ivan_83> on disconnect - device may not exist then script try to chat
Jun 17 20:55:32 <Ivan_83> also add check that disconnect, connect and setmode commands defined
Jun 17 20:56:22 <jow_> okay, so after your change the script will check if the control device exists and is valid and abort early if the control device is invalid
Jun 17 20:56:46 <jow_> so it will not hang for 30 seconds, will not try chat and notify netifd that the device is unavailable
Jun 17 20:57:41 <jow_> but the device remains unconnected in such a situation - or does it eventually recover by itself?
Jun 17 20:58:33 <Ivan_83> recover itself
Jun 17 20:59:22 <jow_> interesting
Jun 17 21:00:01 <Ivan_83> there was many issues with that, first PR was fix replug - it not work without reboot router
Jun 17 21:00:28 <Ivan_83> that pr only improve replug - less errors, less time wait
Jun 17 21:00:36 <Ivan_83> as I remember )
Jun 17 21:01:40 <Ivan_83> you may see logs in pr from user
Jun 17 21:06:59 <jow_> Ivan_83: I think I understood it now
Jun 17 21:07:20 <jow_> Ivan_83: the connect / disconnect / setmode checks are extra safety guards
Jun 17 21:07:27 <jow_> Ivan_83: the device ones too
Jun 17 21:07:38 <jow_> Ivan_83: and the magic is re-reading the manufacturer
Jun 17 21:11:32 <jow_> Ivan_83: https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commit;h=c23fa1de71b58c069caad278ab7db85e7c9d7639 - are you okay with this description?
Jun 17 21:12:29 <Ivan_83> reread manufacturer on disconnect - i see no real case for that but assume that it is possible
Jun 17 21:12:33 <dwmw2> jow_: any thoughts on that 'leak the loop fd' patch?
Jun 17 21:14:07 <Ivan_83> jow_: yes
Jun 17 21:15:30 <jow_> merged
Jun 17 21:15:33 <jow_> dwmw2: not yet
Jun 17 21:16:31 <Ivan_83> jow_: thanks!!!
Jun 17 21:18:11 <jow_> dwmw2: I like it. Clean, simple and sufficiently explained
Jun 17 21:18:24 <dwmw2> not closing the fd sticks in my mouth a little.
Jun 17 21:18:31 <dwmw2> but closing it would be a lot of pain for no good reason
Jun 17 21:18:39 <dwmw2> I've done worse.
Jun 17 21:18:52 <jow_> dito
Jun 17 21:34:57 <ynezz_> poor static analyzers :)
Jun 17 21:44:00 <dwmw2> jow_: thanks.
Jun 17 21:44:09 <dwmw2> I've done the corresponding fstools package update as part of PR#3101
Jun 17 21:44:15 <dwmw2> but I'm done for the evening.
Jun 17 22:54:14 <aparcar[m]> Ivan_83: are you the one creating the freebsd patch?
Jun 17 22:56:13 <Ivan_83> aparcar[m]: yes
Jun 17 22:57:14 <aparcar[m]> I'm wondering if we could run your PR through https://man.sr.ht/builds.sr.ht/compatibility.md#freebsd
Jun 17 22:57:33 <aparcar[m]> it's basically a CI supporting native freebsd and some others
Jun 17 23:00:05 <Ivan_83> why not )
Jun 17 23:14:46 <aparcar[m]> Ivan_83: somewhat works. Some more prerequirements are missing. Does argument passing with freebsd gmake work differently?
Jun 17 23:16:53 <Ivan_83> aparcar[m]: sorry, can you point on path lines, I do not understand gmake context
Jun 17 23:22:27 <aparcar[m]> Ivan_83: https://paste.debian.net/1152597/
Jun 17 23:22:37 <aparcar[m]> I'm trying to bass FORCE=1 or V=s but it doesn't work
Jun 17 23:25:21 <aparcar[m]> Ivan_83: and here is the actual CI https://builds.sr.ht/~aparcar/job/235503#task-setup
Jun 17 23:26:21 <Ivan_83> looks like fail with CC="$(HOSTCC_WRAPPER)"
Jun 17 23:27:52 <Ivan_83> at least bash, perl and something else not installed
Jun 17 23:33:34 <aparcar[m]> Ivan_83: could you give me a list of required freebsd packages?
Jun 17 23:33:54 <aparcar[m]> https://forum.openwrt.org/t/openwrt-build-system-on-freebsd/18266 I'm looking here for answers
Jun 17 23:39:49 <Ivan_83> aparcar[m]: I build on desktop, not shure what exactly required, I already have 700+ installed
Jun 17 23:40:38 <Ivan_83> gcc not required - I spend many time to fix clang build
Jun 17 23:42:42 <Ivan_83> bash, git, wget, ncurses, probably svn, python and perl - may be installed as dep for other ports
Jun 17 23:43:12 <Ivan_83> i mean: "python and perl - may be installed as dep for other ports"
Jun 17 23:44:56 <aparcar[m]> okay well how do I mass an argument using freebsd make so I can see what prerequirements are actually missing?
Jun 17 23:46:20 <Ivan_83> I was simple remove tmp, stage_dir, build_dir and run ./scripts/feeds update -a
Jun 17 23:46:42 <Ivan_83> in prereq-build.mk all checks
Jun 17 23:47:12 <Ivan_83> also gmake required :)
Jun 17 23:47:43 <aparcar[m]> yea but gmake doesn't seem to like V=s
Jun 17 23:48:11 <Ivan_83> are you sure that it was installed?
Jun 17 23:49:03 <aparcar[m]> https://paste.debian.net/1152599/
Jun 17 23:52:38 <Ivan_83> do not run make, run ./scripts/feeds install -a first
Jun 17 23:53:10 <Ivan_83> make -j16 V=s - works after that
Jun 17 23:53:24 <aparcar[m]> I'll try
Jun 17 23:55:36 <Ivan_83> I follow build steps from readme
Jun 17 23:55:50 <aparcar[m]> what about the missing mkhash command?
Jun 17 23:56:08 <aparcar[m]> https://builds.sr.ht/~aparcar/job/235519
Jun 17 23:56:13 <Ivan_83> it is builded from owrt
Jun 17 23:58:26 <aparcar[m]> It seems to be missing and already required for feeds update
Jun 17 23:58:36 <aparcar[m]> so another dependency is missing
Jun 17 23:58:50 <Ivan_83> no, mkhash in owrt
Jun 17 23:58:59 <Ivan_83> awk: calling undefined function asort - here error
Jun 18 00:00:34 <aparcar[m]> well gawk is installed
Jun 18 00:02:06 <Ivan_83> you should see
Jun 18 00:02:06 <Ivan_83> Create index file './feeds/packages.index'
Jun 18 00:02:06 <Ivan_83> Checking 'working-make'... ok.
Jun 18 00:02:06 <Ivan_83> Checking 'case-sensitive-fs'... ok.
Jun 18 00:02:06 <Ivan_83> Checking 'proper-umask'... ok.
Jun 18 00:02:07 <Ivan_83> Checking 'gcc'... ok.
Jun 18 00:02:07 <Ivan_83> Checking 'working-gcc'... ok.
Jun 18 00:02:08 <Ivan_83> ....
Jun 18 00:02:29 <Ivan_83> Checking 'g++'... ok.
Jun 18 00:02:29 <Ivan_83> Checking 'working-g++'... ok.
Jun 18 00:02:29 <Ivan_83> Checking 'ncurses'... ok.
Jun 18 00:02:29 <Ivan_83> Checking 'perl-data-dumper'... ok.
Jun 18 00:02:29 <Ivan_83> Checking 'perl-thread-queue'... ok.
Jun 18 00:02:30 <Ivan_83> Checking 'tar'... ok.
Jun 18 00:02:30 <Ivan_83> Checking 'find'... ok.
Jun 18 00:02:31 <Ivan_83> Checking 'bash'... ok.
Jun 18 00:02:31 <Ivan_83> Checking 'xargs'... ok.
Jun 18 00:02:32 <Ivan_83> Checking 'patch'... ok.
Jun 18 00:02:32 <Ivan_83> ...
Jun 18 00:02:56 <Ivan_83> then run ./scripts/feeds update -a on clean env
Jun 18 00:03:39 <aparcar[m]> I'm guessing the problem is that the CI machine got both awk and gawk installed
Jun 18 00:03:40 <aparcar[m]> but falls back to awk
Jun 18 00:04:39 <Ivan_83> it should not
Jun 18 00:04:46 <Ivan_83> $(eval $(call SetupHostCommand,awk,Please install GNU 'awk', \
Jun 18 00:04:46 <Ivan_83> 	gawk --version 2>&1 | grep GNU, \
Jun 18 00:04:46 <Ivan_83> 	awk --version 2>&1 | grep GNU))
Jun 18 00:04:53 <Ivan_83> gawk check firs
Jun 18 00:05:17 <aparcar[m]> but if both are installed? the rest of openwrt uses awk instead of gawk
Jun 18 00:05:47 <Ivan_83> first sucerful used
Jun 18 00:06:18 <aparcar[m]> https://paste.debian.net/1152601/
Jun 18 00:06:40 <aparcar[m]> this looks to me like both are installed, thats why the prereq check works, however the OpenWrt script then use awk which lacks some functions
Jun 18 00:07:28 <Ivan_83> it check firs gawk, it is ok and it is used
Jun 18 00:07:51 <Ivan_83> if it available
Jun 18 00:08:39 <aparcar[m]> ok
Jun 18 00:09:53 <Ivan_83> check staging_dir/host/bin/ - it should contain simlinks
Jun 18 00:10:40 <Ivan_83> and mkhash, 25 items total
Jun 18 00:10:47 <aparcar[m]> the folder is never created
Jun 18 00:10:55 <aparcar[m]> as /scripts/feeds already fails
Jun 18 00:13:53 <Ivan_83> try to run: env CC=/usr/bin/cc ./scripts/feeds update -a
Jun 18 00:19:08 <aparcar[m]> https://builds.sr.ht/~aparcar/job/235537
Jun 18 00:22:19 <aparcar[m]> sudo -rf /usr/bin/awk
Jun 18 00:22:19 <aparcar[m]> sudo ln -s /usr/local/bin/gawk /usr/bin/awk
Jun 18 00:22:19 <aparcar[m]> this removes the awk error as I guessed before
Jun 18 00:22:31 <aparcar[m]> however mkhash is still missing
Jun 18 00:23:46 <Ivan_83> is it possible that PATH env does not have /usr/local/bin then scripts running?
Jun 18 00:24:46 <aparcar[m]>  Path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/build/bin
Jun 18 00:31:18 <aparcar[m]> Ivan_83: http://azusa.runners.sr.ht/logs/235540/setup/log I'll stop for now, if it builds on your machine than the CI failures are more likely due to my non existing experience with FreeBSD. Thanks for trying to help!
Jun 18 00:32:35 <Ivan_83> i will try on more clean and update readme
Jun 18 00:35:16 <aparcar[m]> https://github.com/aparcar/openwrt-clone/pull/2/files#diff-b1ffd47d4bfb8749d43ab8ddcdda7f56 here is the CI build package selection
Jun 18 00:45:08 <pkgadd> jow: btw., I've just successfully tested WPA3/SAE with pmf=2 on my tl-wr1043nd v1/ AR9132 with https://patchwork.ozlabs.org/project/openwrt/patch/20200615184726.28038-1-mail@david-bauer.net/ applied (no manual module parameters needed anymore), blocktrron thanks :)
**** ENDING LOGGING AT Thu Jun 18 02:59:57 2020