**** BEGIN LOGGING AT Fri Jun 21 02:59:57 2019 Jun 21 04:21:26 is anyone around who can change a tag/label on a github PR? Jun 21 04:23:43 build #323 of brcm2708/bcm2710 is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/brcm2708%2Fbcm2710/builds/323 Jun 21 05:57:42 build #324 of layerscape/64b is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/layerscape%2F64b/builds/324 Jun 21 06:30:13 build #344 of apm821xx/nand is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/apm821xx%2Fnand/builds/344 Jun 21 08:05:48 jow: i see that lua package installs /usr/bin/lua and /usr/bin/luac Jun 21 08:06:42 jow: as part of switching to lua51, should I make those something like /usr/lua51/bin/lua and /usr/lua51/bin/luac ? Jun 21 08:07:11 that would be simple as I could simply change INSTALL_ROOT=/usr to INSTALL_ROOT=/usr/lua51 Jun 21 08:14:29 rmilecki: that would pretty much break all scripts being in production atm Jun 21 08:14:56 I'd keep /usr/bin/lua(c) for the time being and ship 5.2, 5.3 as /usr/bin/lua5.2 and /usr/bin/lua5.3 respectivel jow: ok, how to handle it then? :/ Jun 21 08:15:08 ok Jun 21 08:16:25 jow: do you still think it's safe to rename package from "lua" to "lua51" if we update all DEPENDS? Jun 21 08:24:02 it's probably not about DEPENDS, but also about shebangs Jun 21 08:25:17 ynezz: ? Jun 21 08:25:17 git grep '#!.*lua$' in Gluon return 57 occurences for example Jun 21 08:25:17 ynezz: i need that explained, please Jun 21 08:25:17 #!/usr/bin/lua Jun 21 08:26:51 so it might be less effort to just stick with current lua=lua51 Jun 21 08:26:53 ynezz: that's not what he was asking about :P Jun 21 08:27:35 ok, then I misunderstood it, sorry Jun 21 08:27:52 rmilecki: do you use lede 17.01 with the openwrt kernel 4.4? Jun 21 08:28:11 Hauke: yes Jun 21 08:28:21 rmilecki: I would probably leave lua5.1 to be just "lua" Jun 21 08:28:43 rmilecki: or rename "lua" to "lua5.1" and have it PROVIDES:=lua Jun 21 08:29:52 jow: OK, i was keeping in mind your prev suggestion [11 jun 2019] [08:36:24 CEST] we rename lua to lua5.1, adjust the default library search paths to /usr/lib/lua/5.1 etc. Jun 21 08:30:55 It would be nice if people could tets the current lede-17.01 and openwrt-18.06 snapshots so we can fix some last minute problems Jun 21 08:31:02 rmilecki: yeah, I'm a bit undecided tbh Jun 21 08:31:18 rmilecki: actually changing the library search paths should be fine Jun 21 08:31:48 rmilecki: since scripts usually require "lib", not require "/usr/lib/lua/foo.lua" Jun 21 08:32:45 Hauke: i saw jow's e-mail, but it's soo short notice, i won't manage to do any testing today Jun 21 08:32:49 *too Jun 21 08:34:09 jow: right, but that applies to search paths only, first I think I have to deal with conflicting paths for lua itself Jun 21 08:34:40 like /usr/bin/lua, /usr/include/luaconf.h, /usr/lib/liblua.so and so on Jun 21 09:04:03 jow: uh, another problem, packages use hardcoded paths for installing lua libraries, e.g. libiwinfo-lua has: Jun 21 09:04:05 $(INSTALL_BIN) $(PKG_BUILD_DIR)/iwinfo.so $(1)/usr/lib/lua/iwinfo.so Jun 21 09:05:00 okay, so what about not touching the current ecosystem at all and have the new stuff at /usr/lib/lua5.2 ? Jun 21 09:05:24 i think it's the best idea Jun 21 09:05:44 except... should that be "lua5.2" directory? or "lua-new" or sth? Jun 21 09:06:11 I think /usr/lib/lua5.2 is fine Jun 21 09:06:16 Debian does it as well iirc Jun 21 09:06:18 do you think new/furher lua releases can be backward incompatible? Jun 21 09:06:24 ok Jun 21 09:06:30 basically any new release is backwards incompatible Jun 21 09:06:41 they can be made compatible somewhat, but that requires build time config Jun 21 09:06:48 its better to treat them like different things Jun 21 09:08:47 ok Jun 21 09:09:06 awesome language ;) Jun 21 09:09:07 what needs lua5.2? Jun 21 09:09:21 ~most community has gone with 5.1 or 5.3, 5.2 got left behind. Jun 21 09:09:37 karlp: i plan to look at packaging 5.3 Jun 21 09:09:52 we use 5.2 as example, for discussing 5.1 vs. new releases Jun 21 09:09:54 ok, good, just lua 5.2 in the wordes above. Jun 21 09:10:12 rmilecki: well its like python 2 vs. python 3 - a lot of code simply works or requires minimal changes like `print "foo"` -> `print("foo")` Jun 21 09:10:18 for what it's worth, could we please use the same naming as at least one other distro, rather than inventing our own other way of naming the versions? Jun 21 09:10:40 karlp: and that is...? Jun 21 09:10:42 rmilecki: but code that does... borderline things like using dynamic scoping, function environment etc. will break after lua 5.1 because the entire language concept changed there Jun 21 09:10:42 it's enough of a pain already, even in the u* cmake files. Jun 21 09:11:26 one can emulate lua 5.1 sementics on lua 5.2 or 5.3 by resorting to the debug library, but that is not something one can and should rely on Jun 21 09:11:27 well, fedora et al use lua-5.1 and lua-5.3, and as best I can tell ubuntu is using lua5.1 and lua5.2, Jun 21 09:11:39 so just don't go and pick lua51 and lua52 to be a third way :) Jun 21 09:11:47 since availability of debug hooks is a build time config and its presence is not guaranteed on all lua 5.2/3 implementations Jun 21 09:12:05 karlp: usually we sticked to debian conventions Jun 21 09:12:10 can we use a dot in package name? Jun 21 09:12:14 rmilecki: yes Jun 21 09:12:16 ok Jun 21 09:12:23 so lua5.3 should be fine Jun 21 09:12:28 jow: I'm totally fine if it matches someone :) Jun 21 09:12:37 opensuse uses "lua51" and "lua53", hooray :P Jun 21 09:13:44 yeah, exactly the mess I'm talking about Jun 21 09:13:50 please don't make a fourth :) Jun 21 09:13:52 opensuse packaging FWIW: https://pastebin.com/xB4cTbia Jun 21 09:14:14 we're planning on dropping the library path name patches that remove the "5.1" from the paths on our "default" lua right? Jun 21 09:14:36 karlp: not right now. but we plan to not do that again with lua 5.3 Jun 21 09:14:43 so lua5.1 will become like more traditional lua 5.1 on desktops with the /usr/lib/lua/5.1/blah instead of in the root of /lua? Jun 21 09:14:49 not yet Jun 21 09:15:00 where doyou want to put 5.3? Jun 21 09:15:17 isn't that ~painless and transparent though? Jun 21 09:15:32 as you said, people don't do a "require /path/anme" normally, even if they're allowed to Jun 21 09:16:04 can luci-acme be used to get certificates for machines on the lan, not for uhttpd? Jun 21 09:16:12 the problem is that it needs to happen in a coordinated manner with luci and any other package shipping lua libraries Jun 21 09:16:53 when following debian packaging, it would be /usr/lib/lua/5.3/ Jun 21 09:17:21 which is acceptable imho, even when it intersects with lua 5.1 (no script is going to require "5.3.whetever") Jun 21 09:18:10 isn't right now after a branch a perfect time to do that though? Jun 21 09:18:32 the interpreter will be called /usr/bin/lua5.3 and the compiler /usr/bin/luac5.3 Jun 21 09:18:45 karlp: sure, after the 1000 other things that need to be done Jun 21 09:19:01 sure, I know, but if you don't do it now, I don't think there's much chance of it ever being done. Jun 21 09:19:26 exactly, like that other 1000 things Jun 21 09:19:28 karlp: the next release ;) Jun 21 09:19:48 if you have a personal interest in it, by all means help rmilecki and send patches Jun 21 09:19:51 I'm not opposed to it Jun 21 09:20:17 rmilecki: I can help patch makefiles to update install dirs if you want to go that way, Jun 21 09:20:38 make the transition smooth by still have a /usr/bin/lua -> /usr/bin/lua5.1 symlink and /usr/lib/lua in addition to /usr/lib/lua/5.1 in the default package search path Jun 21 09:20:39 and i'm generally all for the allowing lua5.3 to be installed "as well" as lua5.1 Jun 21 09:20:52 then drop these legacy aliases a few pkg revisions down the road when all others are converted Jun 21 09:20:53 karlp: let me send some early patches today, to don't duplicate work, and then let's see how it goes further Jun 21 09:21:08 that symlink for the path sounds like a great blend. Jun 21 09:21:52 have lua 5.3 only search /usr/lib/lua/5.3 Jun 21 09:22:01 and lua 5.1 search /usr/lib/lua/5.1;/usr/lib/lua for now Jun 21 09:22:06 :+1: Jun 21 09:22:23 then it can just be mechanical work for me or someone to go around finding and cleaning lua packages Jun 21 09:22:53 what are we expecting library packagers to do? installt o both? provide two packages? Jun 21 09:23:13 I'd say migrate to 5.3 Jun 21 09:23:28 stuff required by luci can be moved to luci's contrib repo Jun 21 09:23:36 should I push this to the 18.06 branch_ https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commitdiff;h=71233d01f38c1770db87be19219827fe041367e6 Jun 21 09:23:51 Hauke: yes Jun 21 09:23:54 if "lua" is still 5.1 though, then you're installin librarys that won't be reachable? Jun 21 09:24:32 *shrug* - thats something to figure out :) Jun 21 09:25:18 I suppose there needs to be some library build infrastructure for lua similar to the one for python Jun 21 09:25:28 that's what I was starting to think of .) Jun 21 09:25:37 some lualib.mk or similar which handles the details Jun 21 10:09:11 when was the last time anyone reviewed ixp4xx? Jun 21 10:15:40 I don't see any open PRs for ixp4xx Jun 21 10:16:53 or what do you mean? Jun 21 10:17:31 since it's on 4.9, it's very likely, that it will get removed unless someone upgrades it to 4.19 Jun 21 10:20:35 build #317 of arm64/generic is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/arm64%2Fgeneric/builds/317 Jun 21 10:23:45 ynezz: the reason i'm asking about ixp4xx is that i was looking at what other targets touch CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK and i came across target/linux/ixp4xx/patches-4.9/116-sidewinder_fis_location.patch Jun 21 10:25:14 that should probably have been in the kernel config instead of a patch all alomg Jun 21 10:25:18 *along Jun 21 10:31:33 that patch is 11 years old, so it's likely, that this functionality wasn't there at that time Jun 21 10:34:35 the functionality appears to be much older Jun 21 11:11:26 Is there anything you can do to give softirq top priority. I'm debugging a unit and it appears when a process run it impacts throughputs slightly Jun 21 11:11:33 I'd alaways assumed that softirq maxed the unit out Jun 21 11:32:12 build #311 of brcm2708/bcm2709 is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/brcm2708%2Fbcm2709/builds/311 Jun 21 11:39:35 DonkeyHotei: ixp4xx is borken on 4.14 and 4.19. linusw is working on modernizing it, but that's WiP Jun 21 11:40:48 any idea whether he has access to that specific board? Jun 21 11:41:31 dunno. I have an adi board but that's a pronghorn Jun 21 11:41:37 not a sidewinder Jun 21 11:41:42 does it use redboot? Jun 21 11:41:49 pronghorn? yes it does Jun 21 11:41:58 so does the gateway7001 i have Jun 21 11:42:25 what locations within the flash is the fis directory on those? Jun 21 11:42:40 uh, have to check my notes Jun 21 11:43:25 the patch i mentioned suggests the sidewinder is an odd duck in that regard Jun 21 11:44:38 the pronghorn is: Jun 21 11:44:40 Name FLASH addr Mem addr Length Entry point Jun 21 11:44:44 FIS directory 0x50FE0000 0x50FE0000 0x00020000 0x00000000 Jun 21 11:52:07 build #311 of brcm2708/bcm2708 is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/brcm2708%2Fbcm2708/builds/311 Jun 21 11:52:22 i'm assuming the flash ends at 0x50ffffff? Jun 21 11:52:52 and it has 128k blocks? Jun 21 11:56:30 i'm not 100% sure about the 128k blocks but i recall that's that, yes Jun 21 12:10:20 has super upstreaming powers https://lore.kernel.org/linux-mips/MWHPR2201MB1277BD79F0138BA297E1277DC1E40@MWHPR2201MB1277.namprd22.prod.outlook.com/T/#t serious LOL :-) Jun 21 12:11:02 if it had 64k blocks, CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK would need to be set to -2 for that address, and it doesn't appear to be Jun 21 12:30:53 jow: i sent 2 simple patches, I'll obviously want you to look at them, before I dare to merge them ;) Jun 21 12:31:10 jow: whenever you have some free time, I'm taking a break now from it Jun 21 12:31:22 need to eat some dinner Jun 21 12:32:11 ldir: nice :) Jun 21 12:37:39 jow: I am getting this warning when fetching: WARNING: previous mirror push of repo 'openwrt/openwrt' to host 'git-02' failed, status is: Jun 21 12:37:54 we had the same problem after the 19.07 branch was created Jun 21 12:38:11 I think lynxis manually pushed it to git-02 Jun 21 12:43:10 jow: thanks for tagging the release Jun 21 12:44:54 Hauke: ignore it for now Jun 21 12:45:00 will fix it when I find time Jun 21 12:46:23 git-02 is disabled on the load balancer so people will not have inconsistent states Jun 21 12:46:41 jow: ok Jun 21 14:53:21 Hi people is building ath79 fixt yet? Jun 21 14:55:33 Tapper: not sure what you mean, but the buildbots have no problems with it Jun 21 14:56:12 KanjiMonster I hade a prob building ath79 and ldir hade the same one. Jun 21 14:56:19 had* Jun 21 14:56:27 Are you building on a Mac? Jun 21 14:56:36 If the buildbots are good then I will try again Jun 21 14:56:56 no building in wsl windows 10 Jun 21 14:57:23 I did a make distclean and still got the thing Jun 21 14:57:23 That would likely suffer the same issue the ldir did with the Mac, which has since been fixed. Jun 21 14:57:27 somebody in #openwrt asked why snapshot builds have an older kernel than the 19.07 branch Jun 21 14:57:33 OK thanks Jun 21 14:57:45 s/the// Jun 21 14:58:35 Going to try and build for mvebu first Jun 21 14:59:20 DonkeyHotei: probably because the snapshot builds were older (there were a few issues preventing the buildbots from completing their builds) Jun 21 15:00:37 "but the buildbots have no problems with it" and "issues preventing the buildbots from completing their builds" seem mutually exclusive Jun 21 15:01:51 xgcc: error trying to exec 'cc1': execvp: No such file or directory Jun 21 15:01:51 Makefile:1976: recipe for target 's-selftest-c' failed Jun 21 15:01:51 DonkeyHotei: the build part is working fine, the upload to the download server is failing Jun 21 15:02:24 DonkeyHotei: see http://phase1.builds.lede-project.org/builders (all failures in one of the upload stages, not earlier) Jun 21 15:02:27 Makefile:4250: recipe for target 'all-gcc' failed Jun 21 15:02:27 make[4]: *** [all-gcc] Error 2 Jun 21 15:02:58 Any one know what the heack is going on with my gcc? Jun 21 15:03:36 heck* Jun 21 15:04:52 Fuck it I have dun a make dirclean Jun 21 15:29:57 that libjson-c update has been a complete desaster Jun 21 15:30:12 we should better coordinate things next time Jun 21 15:49:15 and we should implement neoraider's suggestion to enforce direct depends for each library linked Jun 21 15:50:00 basically rework the buildroot *.so dependency checker to *not* consider transient deps Jun 21 15:55:25 I agree Jun 21 16:16:37 How can I best bisect the kernel? Do I use CONFIG_EXTERNAL_KERNEL_TREE with patches manually applied? Jun 21 16:18:46 SibrenVasse: that's the way I am doing when I need Jun 21 16:20:27 using a ramdisk kernel can reduce the amount of patches you need (you can then ignore all the mtd stuff) Jun 21 16:21:45 KanjiMonster: is there an easy way to setup quilt with patches in the external tree? Jun 21 16:24:16 SibrenVasse: no idea. the target i used to bisect needed only a few patches, so never invested any work into automating it Jun 21 16:34:32 SibrenVasse: i always use patch -p1 < ... Jun 21 16:34:55 SibrenVasse: patch is also more grateful when dealing with patches than git am Jun 21 16:54:20 oh man ... the amount of times "git --show-current-patch | patch -p1" dealt with it fine and i go "ffs git" Jun 21 18:02:43 what's the minimal luci package I need to use luci-mod-rpc? Jun 21 18:05:52 jow: what a mess that lua is... no native support for building .so + absolutely meaningless commit messags Jun 21 18:06:17 e354c6355e7f48e087678ec49e340ca0696725b1 ("small updates") Jun 21 18:06:18 f5b0459aba1cf90db8db5136d6719ef4d646a584 ("details") Jun 21 18:06:28 f*ing good desciptions of changes Jun 21 18:08:06 they don't even share COMPLETE sources, wtf https://github.com/lua/lua Jun 21 18:18:09 rmilecki: that github repo is not official, offical source is download tarballs Jun 21 18:18:20 ynezz: i need to see changes... Jun 21 18:18:35 Lua is not developed in open Jun 21 18:18:44 they just release the tarball Jun 21 18:19:39 yeah, I just learnt that and that's why I'm cursing that project ;) Jun 21 18:19:44 ok Jun 21 18:19:48 jeffsf: please fix your connection/client Jun 21 18:20:10 it's 4.19 probably with hw offload on mt7621 Jun 21 18:20:12 they suddenly don't do "-lhistory -lncurses" in new releases anymore and I have no idea why Jun 21 18:23:46 because it's now readline? Jun 21 18:24:08 I'm stuck at 5.1 so I really don't know Jun 21 19:45:09 what about 4.19 with hw offload on mt7621? :) Jun 21 20:11:31 neoraider: ping Jun 21 20:14:10 KanjiMonster: ping Jun 21 20:16:25 jow: news regarding the opkg patch? Jun 21 20:50:53 rmilecki: don't even try and lookk at changes, just accept that they are two packages that happen to have things in common. Jun 21 21:10:44 karlp: that sounds wise Jun 21 21:24:22 circle-ci for the packages feed is failing to download the SDK. It blocks waiting for a password. https://circleci.com/gh/openwrt/packages/3768?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-checks-link Jun 21 22:18:19 anyone ever tried something like this: Have OpenWRT automatically start a serial console if someone plugs in a usb-serial device to the OpenWRT machine? Sort of like a reverse serial console.... Jun 21 22:20:31 I htink mhei was doing something like that, but not based on plugin directly. Jun 21 22:21:00 I've got a usbgadget that offers a serial console and a cdc-ethernet when you plug in, but not everything supports gadget mode. Jun 21 22:21:22 he had some things he was hacking to make sure that it behaved well when the devices weren't there at boot. Jun 21 22:21:25 let me see if I can find it Jun 21 22:22:20 there's a thred "procd console hotplugging support" from jan 2 2019. Jun 21 22:22:20 thanks, that would be welcome. Jun 21 22:22:30 not sure if it got applied sorry. Jun 21 22:23:35 https://patchwork.ozlabs.org/cover/1019861/ Jun 21 22:24:03 that was for creating gadgets with configfs, but .... same? for usb seriaal devices plugged in one would hope? Jun 21 22:24:32 i think the closest you can hope for is netconsole, because afaik there is no kernel support for hotpluggable consoles otherwise Jun 21 22:27:16 netconsole would assume you know the IP though, right? Assume you have some box that boots up and grabs IP from somewhere....it is hard to know its IP unless you have some pretty intimate access to the dhcp server(s) or a serial console. Jun 21 22:27:37 loopback? idk Jun 21 22:27:46 DonkeyHotei: well, mhei had jsut listed the gadget dev name in inittab, and even though it didn't exist at the time, it worked after it was created so? Jun 21 22:28:15 it wouldn't have to be a true kernel 'console', just something that will let you log in on a psuedo tty Jun 21 22:28:25 greearb__: ohhh Jun 21 22:28:45 that should "just work" already Jun 21 22:30:11 I think mhei's patch series was working around bits of that that should have, but might not have. Jun 21 22:30:18 it doesn't appear to have landed anyway Jun 21 22:30:42 oh, might be looking in the wrong tree Jun 21 22:31:14 hhrm, no, not in the procd tree either Jun 21 22:35:09 so if I have a PC with usb port, I would need: usb <-> serial --serial-cable-- serial <-> usb, and plug the usb end into PC and other end into OpenWRT device? Jun 21 22:40:02 why even bother with serial, then? Jun 21 22:40:17 it's usb on both ends Jun 21 22:40:44 because both host ports... Jun 21 22:40:53 thhey don't have a gadget/otg port Jun 21 22:41:13 networking makes more sense Jun 21 22:41:23 to you :) Jun 21 22:41:42 I totally understand teh idea of not having to find the IPs anywhere, just walk up, plug in a cable and be on the _rigght_ device Jun 21 22:42:03 karlp, you know of any hardware widget that would make this easier? Jun 21 22:48:52 nope, if you dont' have an otg/device capable port on the devices, I think your idea is perfectly sane. Jun 21 22:50:19 https://www.digikey.com/products/en?keywords=ftdi%20nmc is the dual serial/usb packkaged up on a nice cable Jun 21 22:50:26 so it's a understood thing Jun 21 22:52:23 I suspect this is similar, if not the same: https://www.amazon.com/exec/obidos/ASIN/B005OTPVMY/metafilter-20/ref=nosim/ Jun 21 22:54:23 that one says "Prolific PL-25A1 chipset" Jun 21 22:54:55 right, but as long as it's 2 usb/seriaal chips back to back, it doesn't really matter whether it's ftdi or prolific or silabls or ... Jun 21 22:55:21 could be more like Ethernet if they are going to do any real transfer over it? Jun 21 22:55:24 though yeah, pl25a1 is a special thing for that windows thing :) Jun 21 22:55:50 explicitly windows easy transfer, so yeah, probaly not what you want, well spotted DonkeyHotei Jun 21 22:57:26 https://www.raspberrypi.org/forums/viewtopic.php?t=131042 Jun 21 23:07:29 neat, good to see tha tthe "windows easy transfer" is well documented Jun 21 23:08:33 stillllll Jun 21 23:08:53 that usbnet cable requires you to knwo what the device has setup as it's networking portion... Jun 21 23:09:10 it's not _quite_ as simple as opening a serial console, but yeah, usb net is going to be faster Jun 21 23:23:32 the openwrt side has to auto-configure one way or another Jun 21 23:29:21 greearb__: just curious, but how is what you want different than that described under 'Router with USB port' here: https://openwrt.org/docs/techref/hardware/port.serial Jun 21 23:29:56 it'ðs exactly that. Jun 21 23:30:13 like donkey saaaid, this should "just work" Jun 21 23:30:54 karlp: guess I missed that, I'll go back to lurking now Jun 21 23:31:06 no, it's good to know it's been written up before :) Jun 21 23:31:22 yeah, I'll try that Jun 21 23:33:07 nmrh: out of curiosity, how are your ipq806x+v4.19+USB experiments going on (I'll have to look into it for ipq8065/ nbg6817 as well, but I'm currently not using any USB attached to my router anyways) Jun 21 23:33:28 i'm building again now... Jun 21 23:33:47 had to take a break to change oil and filter in vehicle Jun 21 23:34:42 good luck Jun 21 23:34:52 make defconfig and menuconfig seem to really want to set the things ansuel suggested i turn off Jun 21 23:35:05 ty Jun 21 23:35:33 check target/linux/ipq806x/Makefile and DEFAULT_PACKAGES, you'll have to remove the conflicting modules there Jun 21 23:36:00 well, at least removing them there will make it easier Jun 21 23:38:06 i'll take a look - hopefully hand editing .config and ignoring 'WARNING: your configuration is out of sync' will work Jun 22 00:16:49 I'm running openwrt-ar71xx-generic-wndr3700-squashfs-sysupgrade.bin at the moment but if I understand it correctly ar71xx is eol and ath79 is it's successor. Does this mean I can use openwrt-ath79-generic-netgear_wndr3700-squashfs-sysupgrade.bin from now on? (looks like it but the ar vs ath confuses me:S) Jun 22 00:18:11 yes. Jun 22 00:18:36 yeah, ar7 is one thing, ar71xx and ath79 are the same Jun 22 00:18:38 hooray Jun 22 00:23:59 will release 18.06.3 be for ar71xx or ath79? Jun 22 00:27:36 18.06.3 is a "minor" point release of the 18.06 release branch, so that remains ar71xx. Jun 22 00:27:42 ath79 is the new world era Jun 22 00:29:18 thanks Jun 22 00:38:34 19.07 will also be ar71xx, but the last one Jun 22 00:38:56 ath79 after that Jun 22 00:39:11 including current master Jun 22 00:49:17 ok but the snapshots dir is `stuck` at Jun 17 does this mean ar71xx snapshots will not be updated? Jun 22 00:50:10 snapshots is "master" which is the brave new world Jun 22 00:50:49 jun 13 ar71xx was marked source only, so no furtherr binary builds Jun 22 01:03:30 that was after 19.07 was branched off, btw Jun 22 01:06:47 qgTG was asking about the "snapshots" which is from master though so relevant aiui Jun 22 01:23:08 well here it goes... Jun 22 02:14:05 usb seems to be working for me on r7500v2 4.19.53... next is the cpu idle and temp sensor things Jun 22 02:14:18 time to go **** ENDING LOGGING AT Sat Jun 22 02:59:57 2019