**** BEGIN LOGGING AT Sat Jul 27 02:59:57 2019
Jul 27 05:08:44 <ynezz> Hauke: staging_dir/host/bin/python points to python3?
Jul 27 05:10:28 <ynezz> Hauke: that error looks like it's python2
Jul 27 06:42:41 <DonkeyHotei> gch981213: so does that mean all the other target/linux/*/base-files/etc/init.d/bootcount files should be changed to match?
Jul 27 07:51:56 <russell--> wireless-regdb isn't building for me, getting python errors
Jul 27 07:56:57 <russell-->   File "/home/openwrt/src/lede/build_dir/target-mips_24kc_musl/wireless-regdb-2019.06.03/dbparse.py", line 3, in <module>
Jul 27 07:57:00 <russell-->     from builtins import bytes
Jul 27 07:57:03 <russell--> ImportError: No module named builtins
Jul 27 08:00:26 <russell--> ah, yeah, Hauke noticed it 13 hours ago
Jul 27 08:34:37 <ldir> can anyone see why https://github.com/ldir-EDB0/packages-1/commit/c46a8d9fb641d252770647fbb34fe48626b6db9b wouldn't work or be a bad idea ?
Jul 27 08:49:34 <rmilecki> karlp: can you provide some extra details on that package description vs. variant vs. buildbots? https://github.com/openwrt/packages/pull/9566#pullrequestreview-266949874
Jul 27 09:17:57 <Hauke> ynezz: probably not
Jul 27 09:28:30 <ldir> Improved description - https://github.com/ldir-EDB0/packages-1/commit/631d2c33a02d6f13765130133a88640c572f9713
Jul 27 09:47:38 <ynezz> Hauke: make -d prereq V=s | grep host
Jul 27 09:50:53 <ynezz> Hauke: if it says, that `Prerequisite 'include/prereq-build.mk' is older than target 'staging_dir/host/.prereq-build' then probably `rm staging_dir/host/.prereq-build` should help
Jul 27 09:51:22 <ynezz> Hauke: I've no clue why this would happen, sorry
Jul 27 09:53:31 <ynezz> Hauke: `touch include/prereq-build.mk` seems to trigger the rerun of prereq target just fine
Jul 27 10:30:58 <karlp> rmilecki: just what you said, using the same style in all places.  I've got no idea why blah-5.1 "works" but blah5.1 doesn't, that doesn't.
Jul 27 10:31:33 <karlp> re suffixes, in other places with variants, there's been problems with the DEPENDS when a variant is the same name as the base name,
Jul 27 10:32:28 <karlp> ie you can have blah-nossl and blah-ssl and PROVIDES=blah, but having a non-suffixed variant screws up opkg or something
Jul 27 10:32:42 <rmilecki> karlp: so now that there is "VARIANT:=lua-51" and "VARIANT:=lua-53" there is no conflict anymore?
Jul 27 10:33:00 <karlp> unlikely, I'v enot seen all the latest, it wasn't there when I commented first.
Jul 27 10:33:05 <rmilecki> ok
Jul 27 10:33:15 <karlp> I'm travelling just saw your tag me here
Jul 27 10:33:29 <rmilecki> thanks for replying
Jul 27 10:36:11 <karlp> I'm not 100% sure this is enough, the base package is sitll "luasocket"
Jul 27 10:37:03 <karlp> not sure depends=luasocket should be matchable by either anyway.
Jul 27 10:37:54 <rmilecki> that's right, and that "luasocket" name is different from both "VARIANT" values, so I hope it's going to work
Jul 27 10:38:52 <karlp> hope for the best :)
Jul 27 10:39:03 <karlp> can't get it right first go anyway,
Jul 27 10:39:25 <karlp> but we want t omake this one as nice as we can because it's the example for all the other new 5.3 variants thta will show up
Jul 27 10:39:50 <rmilecki> i agree
Jul 27 10:40:16 <rmilecki> if that won't work, we'll have to make sure to fix that up quickly, before others copy wrong pattern ;)
Jul 27 10:40:33 <karlp> would have been nice if luasocket had been doing releases like a sane project,
Jul 27 10:40:52 <rmilecki> i wish Lua could do that...
Jul 27 10:41:05 <karlp> what we also need is a way for pure lua projects to work too, with minimal intrusions
Jul 27 10:41:17 <karlp> luasocket is an example of the compiled ones.
Jul 27 10:42:40 <karlp> eh, I don't mind luas releases, there's no surprises at least.  I've got plenty of stuff that works happily on both, just don't use fenv and bitops
Jul 27 10:43:18 <rmilecki> i hate the idea of development behind the doors & just dropping release packages
Jul 27 10:43:47 <karlp> well, it's not behind doors, it's just inside a brazilian univeristy
Jul 27 10:44:01 * karlp shrugs
Jul 27 10:44:06 <karlp> swift/go are the same aren't they?
Jul 27 10:44:18 <rmilecki> really?
Jul 27 10:44:19 <karlp> or ~any of the smaller niche languages?
Jul 27 10:44:20 <rmilecki> uh
Jul 27 10:44:40 <rmilecki> for me not publishing a repo with all commits = behind the doors
Jul 27 10:46:19 <karlp> I personally feel there's more important issues in general, but fair enough :)
Jul 27 10:55:30 <Hauke> ynezz: rm staging_dir/host/.prereq-build
Jul 27 10:55:32 <Hauke> does not help
Jul 27 10:55:43 <Hauke> it looks like this:
Jul 27 10:55:48 <Hauke> ynezz: https://pastebin.com/817d0XUM
Jul 27 10:55:50 <ynezz> rmilecki: https://github.com/lua/lua/commits/master seems like it's slowly changing
Jul 27 10:56:53 <rmilecki> ynezz: oh, interesting, thnaks for alink
Jul 27 11:00:05 <ynezz> Hauke: so for you hostpkg/bin is taking precedence over host/bin ?
Jul 27 11:00:17 <ynezz> rules.mk:TARGET_PATH_PKG:=$(STAGING_DIR)/host/bin:$(STAGING_DIR_HOSTPKG)/bin:$(TARGET_PATH)
Jul 27 11:02:05 <ynezz> include/package.mk:  $(1) : export PATH=$$(TARGET_PATH_PKG)
Jul 27 11:02:39 <ynezz> it makes no sense to me :)
Jul 27 11:03:24 <ynezz> staging_dir/host/bin/python (python3) should be used over staging_dir/hostpkg/bin/python (python2)
Jul 27 11:04:11 <ldir> ynezz: it's working on on macOS - ldir runs & hides
Jul 27 11:06:14 <ynezz> Hauke: http://paste.ubuntu.com/p/n3t4DHwVT6/ (would be interesting to see the PATH set there)
Jul 27 11:06:47 <ynezz> ldir: but you don't have python2 package build from feeds, right?
Jul 27 11:07:21 <ynezz> it seems like Hauke has it (otherwise I can't explain the existence of hostpkg/bin/python binary)
Jul 27 11:09:51 <Hauke> could be that I build python2 from feed some time ago
Jul 27 11:09:58 <Hauke> haven't cleaned this for some months
Jul 27 11:13:23 <ynezz> it makes me wonder how could python2/python3 coexist in hostpkg if this packages create such symlinks
Jul 27 11:24:50 <ldir> ahh! I'm saved... python2 doesn't build on macOS
Jul 27 14:34:33 <ausjke> is ath10k dynamic vlan back-ported to 4.14 for 9.07
Jul 27 14:34:37 <ausjke> 19.07
Jul 27 14:34:54 <ausjke> just searched and it does not seem backported
Jul 27 18:36:06 <blogic> Hauke: ping
Jul 27 18:36:21 <blogic> Hauke: if you could spare a bit of your time in the next few days
Jul 27 18:36:34 <blogic> have some questions regarding xrx500
Jul 27 18:40:37 <xdarklight> blogic: to make sure we're not duplicating work: what are you trying to do with xrx500?
Jul 27 19:03:19 <Hauke> blogic: lets have a call tomorrow
Jul 27 19:16:56 <someoner> Another patch later I got this bootlog: https://pastebin.com/u2zCFjNt
Jul 27 19:17:10 <someoner> I mean it is looking good, but shouldn't I get a login prompt? Or what is expected?
Jul 27 19:18:42 <DonkeyHotei> someoner: did you press Enter?
Jul 27 19:19:07 <someoner> yes
Jul 27 19:19:15 <someoner> nothing
Jul 27 19:20:19 <someoner> I also enabled all debug messages, so I'm not sure what I forgot
Jul 27 19:20:56 <DonkeyHotei> the backtraces might have something to do with it
Jul 27 19:22:29 <someoner> oh, I got used to them. Let me check
Jul 27 19:47:26 <someoner> I'm not sure if these backtraces are the problem. They are warning that the kernel can't compute the backplate clock rate. this also explains the weird uart baud rate I had.
Jul 27 19:51:31 <someoner> I mean the build seems to stop at the moment where the login promt should appear
Jul 27 19:51:47 <someoner> couldn't this be a problem with the userland?
Jul 27 19:52:16 <someoner> maybe I just configured the build wrongly
Jul 27 19:52:59 <DonkeyHotei> aside from the kernel, all defaults would be a sane staring point
Jul 27 19:53:28 <someoner> ok, what would happen if it couldn't find the ramdisk or something like this?
Jul 27 20:01:00 <someoner> Ok I jsut booted vmlinux.elf instead of vmlinux-initramfs.elf: https://pastebin.com/6mDn8ZvA
Jul 27 20:02:08 <someoner> I guess it is able to mount the ramdisk
Jul 27 20:03:02 <blogic> Hauke: oki, i am avail from 1pm onwards
Jul 27 20:10:41 <Hauke> blogic: probably similar for me, currently hacking on BLE
Jul 27 20:16:34 <blogic> I am refactoring ~50 Makefiles from an unnamed silicon vendor ;)
Jul 27 20:25:49 <someoner> I guess "kmodloader: done loading kernel modules from /etc/modules.d/*" is already from the userland?
Jul 27 20:31:38 <Hauke> blogic: ;-)
Jul 27 20:32:59 <someoner> Is there some documentation of the openwrt boot process? Apparently kmodlaoder runs ( https://lxr.openwrt.org/source/ubox/kmodloader.c ), but what happens after this?
Jul 27 20:34:29 <blogic> someoner: kernel starts initd which brings up the rootfs, console loads early modules, runs preinit and then spawns procd
Jul 27 20:34:42 <blogic> procd will start ubus do some watchdog foo and the run inittab
Jul 27 20:34:56 <blogic> inittab will first spawn ttys and then start the services
Jul 27 20:35:13 <blogic> first service is the bootservice which does the rest of kmodloading and overlayfs foo
Jul 27 20:35:30 <blogic> someoner: do you have a specific question ?
Jul 27 20:36:04 <DonkeyHotei> [Sat 2019-07-27 12:17:10 PM PDT] <someoner> I mean it is looking good, but shouldn't I get a login prompt? Or what is expected?
Jul 27 20:36:12 <DonkeyHotei> that was the question
Jul 27 20:36:31 <blogic> not enough context i am afraid
Jul 27 20:36:36 <someoner> blogic: Tahnks for the quick overview! I'm trying to get openwrt running and it hangs on "kmodloader: done loading kernel modules from /etc/modules.d/*"
Jul 27 20:36:54 <someoner> So I'm trying to figure out where exactly it hangs (and why)
Jul 27 20:36:57 <blogic> someoner: can you paste a full log ?
Jul 27 20:37:12 <someoner> https://pastebin.com/u2zCFjNt
Jul 27 20:37:15 <DonkeyHotei> [Sat 2019-07-27 12:16:57 PM PDT] <someoner> Another patch later I got this bootlog: https://pastebin.com/u2zCFjNt
Jul 27 20:37:50 <blogic> someoner: best bet, it loads a module that makes the kernel hang
Jul 27 20:37:57 <blogic> someoner: try booting without any modules
Jul 27 20:38:48 <someoner> Sorry for the dumb question, but how?
Jul 27 20:39:26 <DonkeyHotei> iirc device is a managed switch
Jul 27 20:39:37 <someoner> yes this is correct
Jul 27 20:39:45 <someoner> it is the GS1080T
Jul 27 20:39:45 <blogic> someoner: menuconfig, deselct them all
Jul 27 20:40:08 <someoner> oh I see
Jul 27 20:41:47 <someoner> Aren't there at least some modules required? I mean I need to read the ramdisk etc
Jul 27 20:42:13 <DonkeyHotei> initramfs is not a module
Jul 27 20:46:19 <blogic> someoner: it should boot without
Jul 27 20:48:03 <someoner> OK, I disabled everything I could (some couldn't be disabled). Same result. Maybe I did something wrong
Jul 27 20:52:08 <someoner> I couldn't disable kmod-lib-crc-ccitt, kmod-ip6tables, kmod-ipt-conntrack, kmod-ipt-core, kmod-ipt-nat, kmod-nf-conntrack, kmod-nf-conntrack6, kmod-nf-ipt, kmod-nf-ipt6, kmod-nf-nat, kmod-nf-reject, kmod-nf-reject6, kmod-ppp, kmod-pppoe, kmod-pppox
Jul 27 20:53:21 <DonkeyHotei> there is a way to compile the kernel with additional debug msgs
Jul 27 20:53:48 <someoner> I already did
Jul 27 20:54:05 <someoner> I enabled
Jul 27 20:54:19 <someoner> ignore_loglevel
Jul 27 20:54:52 <DonkeyHotei> not that
Jul 27 20:55:34 <someoner> Ok sorry, than what do you mean?
Jul 27 20:57:10 <DonkeyHotei> there are conditional #defines for pr_debug
Jul 27 20:57:45 <someoner> ok, I'll look into this
Jul 27 20:57:57 <someoner> thanks for the hint!
Jul 27 20:58:34 <DonkeyHotei> i mean there is a global flag for that, but i don't remember where to set it atm
Jul 27 21:06:09 <blogic> someoner: add init_debug=3 or init_debug=4 to your kernel command line
Jul 27 21:06:19 <blogic> that will make procd spew lots of debug during boot
Jul 27 21:06:34 <blogic> incl all hotplug events and imho will alos turn kmodloader debugging on
Jul 27 21:07:51 <DonkeyHotei> but that's is assuming procd actually starts
Jul 27 21:08:51 <someoner> blogic ok, I'll add and and test it
Jul 27 21:09:26 <someoner> DonkeyHotei: The log show "procd: - early -" etc.
Jul 27 21:09:48 <someoner> oh could this be bad? "[   12.386814] procd: failed to set stdio: No such device"
Jul 27 21:13:15 <someoner> I'm getting a lot of debug infos
Jul 27 21:14:06 <someoner> https://pastebin.com/axZvZWQe
Jul 27 21:16:37 <mangix> i love make -j 12. so many hard to see errors
Jul 27 21:17:13 <someoner> Hmm this "failed to set stdio" seems strange https://lxr.openwrt.org/source/procd/state.c#L51
Jul 27 21:18:25 <mangix> implicit declaration of function 'ffs' [-Werror=implicit-function-declaration]
Jul 27 21:18:38 <mangix> ffs is an accurate term to use
Jul 27 21:20:59 <mangix> ping ldir
Jul 27 21:25:42 <DonkeyHotei> i don't make -j 12 on my laptop because i only have 8 threads
Jul 27 21:27:56 <mangix> It's the Ryzen life
Jul 27 21:28:17 <DonkeyHotei> this is an i7
Jul 27 21:28:27 <mangix> they have a lot of l3 cache, which speeds up compilation a lot
Jul 27 21:30:39 <mangix> https://www.gamersnexus.net/images/media/2019/CPUs/r5-3600/games/gcc-compile.png
Jul 27 21:46:48 <karlp> mangix: that eletktra bump to lua 5.3 only seems ot be very much against the idea of allowing lua5.3 to land and co-exist
Jul 27 21:47:24 <karlp> you're taking some extremely preliminary lua5.3 support and using it to justify rmeoving lua support form existing packages
Jul 27 21:48:21 <karlp> I can file a bug that elektra doesn't work on lua5.1 anymore, but I know that won't get the same attention as the broken buildbot that you were "fixing"
Jul 27 22:09:59 <mangix> karlp: it's not that it doesn't work. it's just that when both lua 5.1 and 5.3 are present, lua 5.3 is what ends up getting used by elektra
Jul 27 22:11:54 <mangix> it's a moot point anyway. they maintainer mentioned thinking about removing the lua plugin from elektra.
Jul 27 22:12:06 <mangix> *the
Jul 27 22:46:42 <mangix> gch981213: do you know if breed supports USB on qca9531?
**** ENDING LOGGING AT Sun Jul 28 02:59:57 2019