**** BEGIN LOGGING AT Wed Jul 31 02:59:56 2019 Jul 31 04:28:28 karlp: package/libs/ustream-ssl/Makefile and package/network/utils/iproute2/Makefile Jul 31 07:08:35 I'm having second thoughts on this local tarball thing Jul 31 07:09:05 libs/yajl keeps having different hashes generated for it. Jul 31 07:10:56 and now it went back to the proper one... Jul 31 07:11:03 something is drunk. Jul 31 07:30:27 blogic: enabling ath79 should be possible, sure Jul 31 07:31:17 jow: I think we should enable it Jul 31 07:33:21 no opinion Jul 31 07:33:22 Just enthusiast opinion: enable ath79, just make enough noise in announces / blog /etc that it is beta-quality or something like that, assuming it is that from history conversations Jul 31 07:38:03 Hauke: https://www.openwall.com/lists/musl/2019/07/31/1 Jul 31 07:38:47 Hauke: sounds like something we should have on the radar. Iirc you fixed the mips vdso stuff a while back Jul 31 08:28:07 i've seen some repeated wireless-regdb failures, solved by a make dirclean world, but ... why are they still happening? Jul 31 09:03:20 wut? https://github.com/openwrt/packages/pull/3433 Jul 31 09:05:49 found that while looking for an explanation of the difference between staging_dir/hostpkg/ and staging_dir/host/ Jul 31 09:06:56 rm staging_dir/hostpkg/bin/python ; make -j32 BUILD_LOG=1 IGNORE_ERRORS=m V=s package/wireless-regdb/{clean,compile} ... is working around the failure. Jul 31 09:18:42 python2 seems to be coming from feeds/packages/python Jul 31 09:21:36 lang/python/python-version.mk Jul 31 09:30:56 feeds/packages/lang/python/python may be getting pulled in, in my case, by nmap Jul 31 09:40:50 You’re confirming my own suspicions. Python2 needs host python2 to build. Or it builds host python 2 and then Donald’s the wireless regdb build cos that requires python 3 Jul 31 09:42:37 the staging_dir/hostpkg/bin/python seems to be getting installed from the feeds/packages/python build (if i'm reading my build logs correctly) Jul 31 09:44:28 Yes because python has a build depency on the host/python package. I think. Jul 31 09:45:08 I hit this a few days ago & this is just a guess as to what when wrong. Jul 31 09:45:25 And am typing on phone. Jul 31 09:46:12 * russell-- goes to sleep hoping to wake up to find someone else has fixed the problem ... Jul 31 12:47:37 *yawn* Jul 31 12:57:38 so trying to pick up where russell-- left off - wireless-regdb fails to build with python2 Jul 31 12:58:41 * ausjke thought people are leaving python2 as fast as they could Jul 31 12:58:55 python2 gets built if a package has a dependency on python. python does a host build of python. Jul 31 12:59:29 and that host binary gets placed in staging_dir/hostpkg/bin Jul 31 12:59:58 it gets built as python2 with a symlink from python. Jul 31 13:00:34 now, wireless-regdb just calls $(PYTHON) which is set in rules.mk as (tada) python. Jul 31 13:01:30 so on my mac system I have staging_dir/host/bin with python & python3 linking to /usr/local/bin/python3 Jul 31 13:01:57 staging_dir/hostpkg/bin has python linking to a locally staged python2. Jul 31 13:02:33 and the thing that really blows my mind is that somehow wireless_regdb picks up python2 Jul 31 13:02:52 so rm staging_dir/hostpkg/bin/python and it all works. Jul 31 13:04:16 but NOWHERE can I find a PATH within the wireless_regdb that sets the PATH to include anything that would have hostpkg/bin in it. Jul 31 13:04:43 so how on earth is the package managing to find the wrong version of python? Jul 31 13:06:59 ldir: Jul 31 13:07:00 rules.mk:TARGET_PATH_PKG:=$(STAGING_DIR)/host/bin:$(STAGING_DIR_HOSTPKG)/bin:$(TARGET_PATH) Jul 31 13:07:03 rules.mk:export PATH:=$(TARGET_PATH) Jul 31 13:07:06 ? Jul 31 13:07:53 but I did an @echo $(PATH) in wireless_regdb before it called python and didn't see anything HOSTPKG related. Jul 31 13:12:58 I'd also point out rules.mk:export PATH:=$(TARGET_PATH) != $(TARGET_PATH_PKG) Jul 31 13:17:40 include/package.mk: $(1) : export PATH=$$(TARGET_PATH_PKG) Jul 31 13:20:32 honestly /Users/kevin/wrt/staging_dir/toolchain-x86_64_gcc-9.1.0_musl/bin:/Users/kevin/wrt/staging_dir/toolchain-x86_64_gcc-9.1.0_musl/bin:/Users/kevin/wrt/staging_dir/host/bin:/Users/kevin/wrt/staging_dir/host/bin:/Users/kevin/git/maintainer-tools:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Wireshark.app/Contents/MacOS:/usr/local/MacGPG2/bin Jul 31 13:21:20 from @echo $(PATH) just before $(PYTHON) line in wireless_regdb package make file. Jul 31 13:22:55 I do not understand. And this make wireless_regdb prone to b0rkage if for $reasons we have 'lang/python' enabled in our builds Jul 31 13:24:07 of course I'm only encountering this myself since fixing python2 building on macos, before I was saved from this 'cos it wouldn't build :-) Jul 31 13:26:12 so to sum up Jul 31 13:26:23 building python creates a host python and stages it Jul 31 13:26:40 and then regdb picks this up instead of the os python and borkes ? Jul 31 13:27:02 yes Jul 31 13:27:16 and regdb breaks because it is now python2 and not 3 ? Jul 31 13:27:37 Hello guys. I was curioust about how TP-LINK partition tables are used - since I am under the impression that even stock firmware is not using it in the Archer C60 V2. What does safeloader do exactly? As I understood it, it seem to be a bootloader but I don't think it's on my device. Jul 31 13:27:41 yes Jul 31 13:27:58 and why do we export a partition table at the had of our images? Jul 31 13:27:59 ldir: and can we fix regdb ? it should be python version agnostic or not ? Jul 31 13:28:36 Is the partition table on the device altered based on the image informations? I was looking around in the gpl source code for the device to see if I can find the partition parser, but I didn't... Jul 31 13:29:34 blogic: i don't know. From reading around it requires at the very least something called 'python2-future' Jul 31 13:29:54 -machine-learning-cloud-container Jul 31 13:30:11 -AI Jul 31 13:30:38 ldir: can we make it use python3 instead of python ? Jul 31 13:30:51 if i recall python is an alias to one of the versions Jul 31 13:31:01 * blogic notes that his debian has 6 versions of python Jul 31 13:31:09 so much for interop compat Jul 31 13:31:37 blogic: and of course, any distro has it's default for the "python" symlink Jul 31 13:32:11 blogic: check liblua and openssl too Jul 31 13:32:45 currently i have liblua5.1, 5.2 and 5.3, and neither can be kicked off the box as one or more _foo_ is dependant on either Jul 31 13:33:18 ldir: please tell me how it's possible, that you don't have hostpkg/bin in the path, yet regdb uses hostpkg/bin/python :p Jul 31 13:33:33 I don't know. Jul 31 13:33:51 well, if you find it out, then you can fix that issue Jul 31 13:35:10 I was trying to help out russell-- or more like follow up because I saw something similar a few days ago that a makedir clean sorted out. Jul 31 13:35:31 Hauke had the same issue Jul 31 13:36:02 right, so there is a problem and none of us are imagining things. Jul 31 13:37:17 it appears to be summed up as 'staging_dir/hostpkg/bin/python is used in preference to staging_dir/host/bin/python' Jul 31 13:37:35 http://paste.ubuntu.com/p/n3t4DHwVT6/ Jul 31 13:38:28 Hauke figured that one already, but then I've asked for env values before the call to the python Jul 31 13:39:35 changeing the title in x86 e.g. 000-Generic.mk doesn't change anything in make menuconfig, is the process different there? Jul 31 13:40:56 how the hell can @echo $(PATH) be different from env > $(TOPDIR)/env-$(PKG_NAME).txt - because as sure as **** it is! WTF Jul 31 13:42:09 PATH is a var in the scope of make and env is the env outside Jul 31 13:42:32 aparcar[m]: long standing bug Jul 31 13:42:39 aparcar[m]: rm -rf tmp/ fixes it Jul 31 13:43:44 blogic: how come it works for other targets? Jul 31 13:43:59 ynezz: ATH=/Users/kevin/wrt/staging_dir/target-x86_64_musl/host/bin:/Users/kevin/wrt/staging_dir/hostpkg/bin:/Users/kevin/wrt/staging_dir/toolchain-x86_64_gcc-9.1.0_musl/bin:/Users/kevin/wrt/staging_dir/toolchain-x86_64_gcc-9.1.0_musl/bin:/Users/kevin/wrt/staging_dir/host/bin:/Users/kevin/wrt/staging_dir/host/bin:/Users/kevin/git/maintainer-tools:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Wireshark.app/Contents/MacOS:/usr/local/Mac Jul 31 13:43:59 GPG2/bin Jul 31 13:44:20 nice, so fix it :) Jul 31 13:44:56 staging_dir/host/bin:staging_dir/hostpkg/bin should be correct Jul 31 13:45:37 so somewhere the extra target-x86_64_musl is creeping in. Jul 31 13:45:54 but there is no python or is there? Jul 31 13:46:10 the issue is hostpkg/bin being in the path before host/bin Jul 31 13:46:56 or is it intended? Jul 31 13:47:05 blogic: anyway that fixed it for now, thanks! Jul 31 13:53:20 ldir: BTW looking at the regdb package again, I think, that it's wrong Jul 31 13:53:40 no, there's no python in staging_dir/target-x86_64_musl/host/bin Jul 31 13:53:58 ldir: regdb simply doesn't use host build, but target build Jul 31 13:54:13 that's why it's leaking this target crap into the path Jul 31 14:04:17 ynezz: Beyond my understanding I'm afraid Jul 31 14:05:47 Build/Compile is for target, it should use Host/Compile Jul 31 14:09:35 in other words, it's going to have different env variables Jul 31 14:17:15 Does anyone have a clue, why there is 640-bridge-only-accept-EAP-locally.patch ? What use cases does it cover? I mean, it's changing the default Linux behavior, thus it woud be better to have it as config option "[x] Enable various kernel hacks" disabled by default Jul 31 14:17:30 context https://patchwork.ozlabs.org/patch/1137710/ Jul 31 14:17:38 (putting aside, that this patch is wrong) Jul 31 14:18:31 and https://github.com/openwrt/openwrt/pull/2039 and https://github.com/openwrt/openwrt/pull/2266 Jul 31 14:20:29 we could probably enable those hacks in the snapshot builds, but don't do this for releases Jul 31 14:23:41 pepe2k: Do you have any tips on how to open the Alfa Tube-E4G? For some reason, my device fails to boot when I try to install the latest snapshot on it Jul 31 14:29:47 AFAIR you need a special key/tool for that Jul 31 14:30:00 yeah, my feeling tool Jul 31 14:30:04 "special" Jul 31 14:30:13 suspect brute force will be the way ... Jul 31 14:30:38 or just way for a picture of that tool so you can make something similar yourself Jul 31 14:30:45 s/way/wait/ Jul 31 14:32:01 is adrianschmutzler here? Jul 31 14:32:18 my collegue who has more experience breaking up stuff than me somehow managed to open it with a screwdriver Jul 31 14:32:30 and it is possible to reassemble the device Jul 31 14:32:49 so I declare victory and know who I will go to next time :) Jul 31 14:47:24 I don't know if this is something I am doing (I have a small set of config scripts running), but in order to get the network to work on the device I needed to switch from the current ucidef_set_interface_lan "eth0" and add a switch instead Jul 31 14:49:24 the board itself boots just fine, so it was just networking that has failed Jul 31 14:51:33 procd can handle hotplug well, how can my c code handle hotplug, e.g. a usb device file disappears from /dev, how can my C code detect that, monitoring uevent via netlink socket? Jul 31 14:52:17 my uvc code does not work reliably when the usb-camera was hotplugged frequently Jul 31 14:53:25 is it a better idea to inotify any just-opened-device-file so the application knows when it disappears and close it immediately(e.g. hotplug) Jul 31 16:19:32 ldir: so maybe this https://git.openwrt.org/fecd5ef90c39a8f017615134421de7983e9a47b8 ? Jul 31 16:20:15 russell--: ^ Jul 31 16:25:35 jow ynezz could you please check out this PR (again) https://github.com/openwrt/openwrt/pull/2192 ? Once merged it would very much improve the sysupgrade server as I could do a major refactor Jul 31 16:39:40 ynezz: I can confirm it works for me. thanks. Jul 31 16:40:29 I should never have made python2 work on macos ;-) Jul 31 16:48:02 ausjke: extend /etc/hotplug.json Jul 31 16:48:14 syntax should be self explaining more or less Jul 31 16:49:17 jow: ping Jul 31 16:49:19 okay, you should've read your question more carefully. Extending /etc/hotplug.json would allow you to add rules which will execute a command once usb devices come or go Jul 31 16:49:26 blogic: pong Jul 31 16:49:36 looks like i managed to get prpl to fund servers Jul 31 16:50:05 ausjke: if you really want to handle hotplug from your daemon and not rely on external commands or signals, then you do need to listen for kernel uevents, yes Jul 31 16:50:19 blogic: that's awesome news. I've just noticed that you tried to call Jul 31 17:09:54 ynezz: going to sleep worked! ;-) thanks all Jul 31 17:32:28 blogic: could you elaborate? Jul 31 17:48:09 jow: if the general tiume64 interface are avalibale in kernel + musl I can add the mips vdso part, I already debugged this and this does not lok so compliated Jul 31 17:48:41 jow: as we also ship the kernel I do not think this is a big problem Jul 31 18:21:28 jow: shouldn't this be removed from the download server? It contains files starting with lede- https://downloads.openwrt.org/snapshots/targets/ppc44x/generic/ Jul 31 19:01:49 is there a timeline for getting ynezz's wireless-regdb patch (and maybe my scons update patch) committed to master? i don't mind patching locally, but i've got less-openwrt-indoctrinated people trying to duplicate our node building process, reducing the local patch load would help them. Jul 31 19:43:38 russell--: I guess when ynezz decides to do it. Jul 31 19:45:09 I'm reluctant to push other's commits to trees 'cos I feel like I'm stepping on toes. Jul 31 19:50:37 ever the gentleman =) Jul 31 19:52:26 you say gentleman, I say coward. Jul 31 20:01:01 for the record, i more asking what the process was, if the pause was due to waiting for something and what that might be. Jul 31 20:03:32 I'm not sure there is a process. If you send an 'ack' 'works for me' or similar then it might help. Jul 31 20:04:20 or if I were exceptionally mischievous I could suggest you send your own patch in to patchwork and I could commit that. Jul 31 20:05:26 * Borromini imagines ldir doing a mr burns Jul 31 20:06:37 * ldir releases the hounds on Borromini Jul 31 20:07:07 * Borromini crawls back into his safe space Jul 31 20:09:18 lol, no thanks. Jul 31 20:34:29 russell--: I hope, that someone from package feeds is going to accept/merge that scons move PR soon, as it makes no sense for me to include your bump into that pending PR now Jul 31 20:35:26 russell--: so ideally you could simply just summon PR with your fix against package feed repo Jul 31 20:38:12 ynezz: i don't understand "summon" Jul 31 20:38:48 cast a spell? Jul 31 20:38:50 :) Jul 31 20:40:02 but if the transition is not done next week, then I'll simply merge your fix and update the PR Jul 31 20:40:49 if it helps, i can create another pull request with my bump in packages if that's what you mean Jul 31 20:41:17 but I'm not sure if it's going to work as scons is not yet in the packages repo Jul 31 20:41:52 it's just holidays, so I would be just patient, it's not a big deal, right? Jul 31 20:42:32 not for me, but for people who wonder why they can't replicate our build process Jul 31 20:42:51 "our" == my community wireless network Jul 31 20:44:37 xback: i'm seeing a kernel config query: " Asix PHYs (AX88796B_PHY) [N/m/y/?] (NEW) " during an ath79 build Jul 31 20:45:07 maybe you should try to bribe^Wmotivate stintel with some beers to merge that PR :) Jul 31 20:52:33 fwiw, i've tested https://git.openwrt.org/fecd5ef90c39a8f017615134421de7983e9a47b8 (the wireless-regdb patch) and it works for me too. Jul 31 20:54:13 ok, thanks for info Jul 31 20:54:24 seems like it's safe to update scons in the main openwrt tree and move it to packages in a separate step later **** ENDING LOGGING AT Thu Aug 01 03:00:25 2019