**** BEGIN LOGGING AT Wed Dec 19 03:00:02 2018 Dec 19 04:50:33 so 4.19 is in right? Dec 19 05:52:23 yes and no, generic 4.19 and a few selected targets (x86, lantiq, ath79 and ipq40xx with pending pull requests), but it won't become the default for any target until after 19.01.0 Dec 19 05:56:29 yeah thats fine, I live on the edge anyway :D Dec 19 06:01:05 morning Dec 19 06:01:27 pkgadd: regarding 4addr fix... I thought there's a v2? I'm a bit lost with context Dec 19 06:03:22 I'm gonna revisit tunnel stuff today, may need some help Dec 19 06:04:53 the netifd (I think?) handler is generic enough right? I can see there are definitions for a whole bunch of tunnel types and modes Dec 19 06:05:05 so it should be possible to handle it in a generic proto script? Dec 19 06:10:25 also umm, unrelated, is there a reason nf_conntrack_acct and checksum are disabled? is that a performance or memory overhead thing? Dec 19 06:12:59 are they disabled? I though they're just present in external modules Dec 19 06:13:24 nlbwmon relies on conntrack accounting for traffic monitoring, so it used to be enabled at least at some point in the paszt Dec 19 06:13:45 net.netfilter.nf_conntrack_acct=0 Dec 19 06:13:45 net.netfilter.nf_conntrack_checksum=0 Dec 19 06:13:51 in the default sysctl.conf (x86, anyway) Dec 19 06:14:20 does the contents of sysctl.d/ override those defaults? Dec 19 06:14:46 I only noticed coz I was wondering if I should just remove conntrack_max, since the kernel will pick the buckets based on ram amount anyway Dec 19 06:23:10 jwh: ah you mean the sysctl Dec 19 06:23:14 yeah Dec 19 06:23:16 yeah, this is off for performance Dec 19 06:23:22 ah ok Dec 19 06:23:38 that means theres no flow accounting right? Dec 19 06:23:55 I wonder if that was tripping ipt-netflow up Dec 19 06:29:50 likely Dec 19 06:31:07 hm, any idea how heavy the impact really is? Dec 19 06:31:51 nope Dec 19 06:32:09 guess I should test it Dec 19 06:32:47 can't imagine it would be that horrific on reasonably quick xeons though, with flowoffload Dec 19 06:36:55 jow: apparently there was supposed to come a v2 fix for 4addr, but that hasn't materialized over the last 5 1/2 weeks so far Dec 19 06:37:25 pkgadd: and the v1 fix works too? Dec 19 06:37:44 sorry, I need very ... clear ... and ... simple instructions :) Dec 19 06:37:47 jow: yes, tested upon r8810-09004e6e13 Dec 19 06:38:11 like "please pick on top of because it fixes " Dec 19 06:38:34 the sha1 I can google Dec 19 06:39:35 https://gist.github.com/keithwky/23fdff907c23df57d35ee052fbd44cf6 on top of master, that is https://lore.kernel.org/linux-wireless/1542798228-3293-1-git-send-email-mpubbise@codeaurora.org/ Dec 19 06:39:55 it's not merged anywhere so far, pending the -missing- v2 revision of that patch Dec 19 06:41:00 thanks! Dec 19 06:41:13 morning Dec 19 06:41:44 morning blogic Dec 19 06:42:55 jow: hi there Dec 19 06:43:03 sorry i am still useless Dec 19 06:43:25 i gave up my hope to get anything done this year Dec 19 06:43:34 and will start fresh in 2019 Dec 19 06:43:54 i was planning to bump some targets to 4.19 next week ? is this on our agenda ? Dec 19 06:44:15 my agenda (roughly): Dec 19 06:44:20 - 18.06.2 Dec 19 06:44:36 - 17.01.7 (final) Dec 19 06:46:28 I don't really care about 4.19 yet Dec 19 06:47:22 blogic: it would be great if you could skim through https://git.openwrt.org/?p=openwrt/staging/jow.git;a=shortlog;h=refs/heads/backport-18.06 and identify things that should go into 18.06 Dec 19 06:47:31 ok Dec 19 06:47:33 all commits in there should apply cleanly to openwrt-18.06 Dec 19 06:47:44 its a master rebased on top of openwrt-18.06 Dec 19 06:51:55 jow: there is a lot Dec 19 06:51:57 * jow is going to look into the epic iproutw2 fallout Dec 19 06:52:10 what happened there ? Dec 19 06:52:34 libelf came to be and iproute2 started to depend on it Dec 19 06:52:37 autotools glory Dec 19 06:52:58 why on earth does it need libelf? Dec 19 06:53:00 gory more like Dec 19 06:53:28 jwh: well because in this modern age we upload executable objects to the kernel Dec 19 06:53:36 through tc Dec 19 06:53:37 oh for eBPF stuff? Dec 19 06:53:40 right Dec 19 06:53:41 ugh Dec 19 06:53:48 jow: what could possibly go wrong Dec 19 06:53:51 I'm sure someone wrote a tiny compiler for exactly that reason Dec 19 06:54:01 blogic: nothing, its all great Dec 19 06:54:24 dependency on libelf is ridiculous Dec 19 06:54:46 I gave up asking Dec 19 06:55:02 ip-full increased by 40KB or so between 17.01 and 18.06 Dec 19 06:55:32 without apparent changes in features Dec 19 06:56:03 blogic: so you say there's a lot of commits that should be picked? Dec 19 06:56:05 bet its one of those things where it depends on an entire library for a couple of small functions they could have just imported Dec 19 06:56:39 blogic: then the simplest would be if you make a for-18.06 branch in your repo where you simply cherry-pick all jow/backport-18.06 commits you deem important Dec 19 06:56:51 I'll take care of assembling and build-testing them then Dec 19 06:56:53 i'll try to do that Dec 19 06:57:20 otherwise a plaintext pastebin is okay too Dec 19 06:58:44 jwh: apparently there's also a lot of json stuff in iproute2 now Dec 19 07:00:35 oh Dec 19 07:01:04 oh yeah... -j Dec 19 07:01:14 at least thats kinda useful Dec 19 07:03:11 at least the json stuff doesn't appear to require an external library Dec 19 07:03:27 it just adds code size in all modules Dec 19 07:03:45 yeah, it should really be a compile time option Dec 19 07:04:28 dammit, I still cannot reproduce the iproute2 problem Dec 19 07:10:49 ah, the offending commit got removed Dec 19 07:11:22 ldir: reverting "elfutils: install library files for pkg-config" was not enough to get rid of the already install *.pc files Dec 19 07:11:44 I think because there is/was no UninstallDev directive in elfutils Dec 19 07:14:57 meh Dec 19 07:15:06 the iproute2 build system is really lazy Dec 19 07:15:19 if they happen to find libelf, they just link it everywhere Dec 19 07:15:30 even to ip, ss, etc. not just tc Dec 19 07:26:26 jow:are you referring to this bugreport https://bugs.openwrt.org/index.php?do=details&task_id=2011 ? Dec 19 07:27:24 dedeckeh: yes, problem is https://downloads.openwrt.org/snapshots/faillogs/mips_24kc/base/iproute2/tiny/compile.txt Dec 19 07:27:56 dedeckeh: as soon as a valid libelf.pc exists (pkgconfig --{c,ld}flags libelf works), iproute starts to link it Dec 19 07:28:57 jow:so even with the revert done by ldir the issue is still hit ? Dec 19 07:29:34 dedeckeh: yes because the staged libelf.pc is still present after the revert (buildbot builds incrementally) Dec 19 07:29:56 ah ok Dec 19 07:30:12 this also mirrors the situation of most buildroot users Dec 19 07:30:37 anyhow, I liik into it now to see if we can improve it Dec 19 07:37:06 as you said the iproute2 huild system is indeed lazy; for libmnl we also have a patch as it links against this lib if it's found Dec 19 07:37:46 right now they link libpf to the static libutil.a Dec 19 07:37:53 which means all tools start to depend on it too Dec 19 07:38:02 as suspected, the only actual user is tc Dec 19 07:38:23 jow@wws-7:/tmp/iproute2-4.19.0$ grep -lrE 'bpf_(send|recv)_map_fds' . Dec 19 07:38:23 ./tc/m_bpf.c Dec 19 07:38:23 ./tc/e_bpf.c Dec 19 07:38:23 ./tc/f_bpf.c Dec 19 07:38:23 ./include/bpf_util.h Dec 19 07:38:25 ./lib/libutil.a Dec 19 07:38:28 ./lib/bpf.o Dec 19 07:38:30 ./lib/bpf.c Dec 19 07:39:12 will see if it can be untangled Dec 19 07:40:47 mmmm, having it as an option would be nice Dec 19 08:07:40 build #311 of zynq/generic is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/zynq%2Fgeneric/builds/311 Dec 19 08:28:31 build #1160 of x86/geode is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/x86%2Fgeode/builds/1160 blamelist: Petr ?tetiar , Stijn Tintel , Yousong Zhou , Michael Heimpold , Biwen Li , Tony Ambardar Dec 19 08:28:31 , Stefan Lippers-Hollmann , Yangbo Lu Dec 19 08:36:56 build #308 of layerscape/32b is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/layerscape%2F32b/builds/308 Dec 19 08:41:31 does PCIe work with ath79 on kernel 4.19? In my latiq port it does not work Dec 19 08:42:28 Hauke: It works on AR9344. Dec 19 08:45:17 gch981213: ok thnaks for the information, then I have to search for the lantiq specific bug. Dec 19 08:47:25 mornin' Dec 19 08:58:08 Ycarus: in case you missed it, brcm2708 is at 4.14 ;-) Dec 19 08:58:15 build #308 of mxs/generic is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/mxs%2Fgeneric/builds/308 Dec 19 08:59:23 dedeckeh: https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=cd20baf6edd4be12ea4077880654dbdcbc5a61ba Dec 19 08:59:39 the patch would be a lot simpler if the bpf elf stuff were in a separate C file Dec 19 09:24:15 build #308 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/308 Dec 19 09:25:40 stintel, I will test that ;) Dec 19 09:46:42 * ldir hangs head in shame - morning! Dec 19 09:47:21 jow:thx, do you think the patch would be acceptable for upstream ? Dec 19 09:47:36 dedeckeh: don't think so Dec 19 09:47:42 will work on a different approach for upstream Dec 19 09:48:02 the elf stuff simply needs to go into a separate object file Dec 19 09:48:14 agree that would make it simpler Dec 19 09:48:22 then its only a matter of adding the -lelf to the tools where it is needed Dec 19 09:48:27 the rest will be taken care of by the ld Dec 19 09:48:55 build #307 of omap/generic is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/omap%2Fgeneric/builds/307 Dec 19 09:49:32 * ldir offers profuse thanks for you both looking into this Dec 19 09:50:58 fix pushed, bbl Dec 19 09:51:36 jow: should think you need to lie down after that :-) Dec 19 09:52:04 speaking of ebpf, does anything from the embedded vendors support it yet? Dec 19 09:52:18 like soc stuff, not standalone nics Dec 19 09:57:28 Mornin' all Dec 19 09:57:42 Jow: just red that a 17.01.7 is scheduled? Dec 19 09:58:05 I bumped 4.4 already, but not yet 3.18 as the delta is huge and a lot of work Dec 19 09:58:23 want me to throw some effort at it? Dec 19 10:01:53 hi, does 17.01 accept new patches at least for fixes like a backport? Dec 19 10:10:31 ldir:credits should go to jow; he did the heavy lifting :) Dec 19 10:12:28 i just create the chaos that he has to sort out - doh! Dec 19 10:14:37 * ldir thinks.... Dec 19 10:17:27 build #308 of mpc85xx/generic is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/mpc85xx%2Fgeneric/builds/308 Dec 19 10:17:37 if my elfutils revert is effectively ignored....and nothing else has obviously blown up....is it now ok to put the elfutils patch (with package bump) back? Dec 19 10:27:32 * ldir is a dingleberry - jow has already done it!!! ah but without the package bump. hmmm. Dec 19 10:33:06 at the risk of poking the hornets nest again.... does https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4b4e6a04ac918d5cce2d168d9e656f3d2a29ec4b technically need a PKG_VERSION bump? Dec 19 10:33:20 danitool: backport that fix actual bugs, yes, new feature backports not Dec 19 10:33:46 PKG_RELEASE bump I mean Dec 19 10:36:00 stintel: how should I make the title, something like "[PATCH]: 17.0.1 backport: target: my fix" ? Dec 19 10:37:03 danitool: ideally it can be cherry-picked from master and you just mail a request to cherrypick $COMMITHASH to 17.01 Dec 19 10:37:27 or even ask here Dec 19 10:37:31 ldir: my rule would be if opkg needs to treat it as a newer version (because the contents of the .ipk changed), then yes; for stuff that only affects the build process, then it's not as critical Dec 19 10:37:35 if no response -> ML ? Dec 19 10:38:26 stintel: does it mean that I don't neet to make any patch? Dec 19 10:39:14 KanjiMonster: thanks - in that case it's ok as it is. I think :-) Dec 19 10:39:46 danitool: if it can be cleanly cherrypicked from master, you do not Dec 19 10:40:19 I just wantet to backport this commit made by KanjiMonster some days ago https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=e08ef42b24f Dec 19 10:40:46 xback: kernel 3.18 is not supported in lede 17.01 Dec 19 10:41:12 danitool: ah, will be difficult to cherry-pick - 17.01 uses 4.4 kernel Dec 19 10:41:27 danitool: these fixes should go to 18.06 first ;) (I can also push them to 17.01 then) Dec 19 10:41:39 danitool: yes backports are allowed for lede 17.01, best is to send a mail with thecommits you needed backported to the mailing list Dec 19 10:41:44 stintel: at least that one should apply cleanly to 4.4 as well Dec 19 10:41:50 KanjiMonster: can you backport https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=e08ef42b24f to 17.01 ? Dec 19 10:42:15 it shouldn't break anything on the kernel Dec 19 10:42:25 hauke: ok noted. Dec 19 10:42:37 stintel: as I said, I will once I'm finished with fixing other issues in master, then I'll backport those fixes to 18.06 and 17.04 (as applicable) Dec 19 10:42:46 KanjiMonster: alright :) Dec 19 10:43:12 ah, I missed that line :) Dec 19 10:43:59 nbd: Would you ack this one? they got tagged towards Dave Miller this morning: https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=10822ca52ccad6e88707b1936e37aff38fef3461 Dec 19 10:45:09 checked for other fixes regarding *80211 but all other are already included Dec 19 10:46:15 danitool: when I tried booting a 6348 to debug the pinmux issue I found other issues that I need to fix (where I have no idea how they never cropped up before) Dec 19 10:47:08 code that should have triggered a null pointer access since 2009 - but didn't in previous releases Dec 19 10:48:41 right now my livebox doesn't boot ok with a redboot bootloader, but it does with CFE Dec 19 10:51:51 KanjiMonster: about the pinctrl issues in bcm6348, I also noticed that the group0 must be wrong, I would say that it only owns the GPIO32 for MII MDC Dec 19 10:51:52 danitool: https://elixir.bootlin.com/linux/latest/source/arch/mips/bcm63xx/dev-dsp.c#L51 this code - bcm63xx_voip_dsp_device.dev.platform_data is obviously NULL, so no idea why it didn't blow up before Dec 19 10:52:19 danitool: the mask/shift calculation is wrong, it always uses group0 - it's a two line change that fixes it Dec 19 10:53:07 basically I the macro expects the pin number, but I use the group number, which results in always using group 0 Dec 19 11:41:22 man ubnt make some cute little boxes these days, so many new ones Dec 19 11:42:01 https://store.ubnt.com/collections/routing-switching/products/edgeswitch-10xp-1 Dec 19 11:42:05 looks kinda pretty Dec 19 11:42:15 cheap too Dec 19 11:42:32 wonder what soc that is Dec 19 11:47:36 64 0x40 gzip compressed data, maximum compression, has original file name: "vmlinux_org.bin", from Unix, last modified: 2018-11-02 15:01:07 Dec 19 11:47:43 nice gpl compliance Dec 19 11:49:08 have you bought one? Dec 19 11:49:14 maybe the written offer is only in the box... Dec 19 11:49:35 no Dec 19 11:49:37 lol Dec 19 11:49:52 they stopped posting GP code a while back, previously they were pretty good Dec 19 11:49:55 GPL* Dec 19 11:49:59 also, soc is realtek Dec 19 11:50:05 Linux version 3.18.24 (ubnt@380c9fb148f5) (gcc version 4.8.5 20150209 (prerelease) (Realtek MSDK-4.8.5p1 Build 2220) ) #2 Fri Nov 2 15:01:06 UTC 2018 Dec 19 11:50:08 3.18 on a 2018 product Dec 19 11:53:54 jwh: 3.18 is still receiving updates (despite being EOL), so it can be okay. obviously not okay if you don't apply them Dec 19 11:54:13 well, given the gcc version it's likely just an old chip Dec 19 11:54:21 or they haven't bothered updating it, ever Dec 19 11:54:55 what I wanna know though is why ubnt suddenly think its ok to not post sources Dec 19 11:59:47 they can't update the kernel because of the crappy vendor sdk Dec 19 12:00:03 I really feel for people running edgeos on their production hardware Dec 19 12:00:12 s/hardware/network/ Dec 19 12:00:57 it's a disaster waiting to happen with all the security bugs that keep popping up Dec 19 12:01:50 its largely a silicon vendor problem Dec 19 12:01:57 eedgeos 2 has 4.9 Dec 19 12:02:01 edgeos* Dec 19 12:02:16 but they've had to wait for both mediatek and cavium to release new sds Dec 19 12:02:18 sdks* Dec 19 12:02:36 but ubnt could have pushed both vendors for newer kernels sooner Dec 19 12:03:05 problem is because they settled for 4.9, it'll be a few years before it gets another bump Dec 19 12:03:18 could be 5 or more Dec 19 12:03:46 4.9 is at least new enough though Dec 19 12:03:49 stintel: got a rpi 3 model B. so I can test that model on 4.14 if you like Dec 19 12:04:02 xback: everything should be fine ;-) Dec 19 12:04:06 maybe the hdmi issue also shows up there Dec 19 12:04:39 xback: maybe we can trigger the vmalloc issue with "while true; do insmod jitterentropy_rng; done" Dec 19 12:04:55 ah but that would load just fine on rpi3 Dec 19 12:05:11 true, but it does not explain why it worked with HDMI attached Dec 19 12:06:00 indeed. could it be that the module that handles FB/HDMI/VC4 or so causes compaction on mem area for vmalloc ? Dec 19 12:06:27 I hope to find out asap if I can simulate it on this model Dec 19 12:06:34 there is something that appears to use more memory when HDMI is attached. that's the only thing I can think of (but it's a wild guess, I know *nothing* about vmalloc) Dec 19 12:06:45 jwh: hmm, ubnt going realtek? haven't expected that Dec 19 12:07:04 xback: I don't have kmod-crypto-rng enabled on my 3b+ Dec 19 12:07:11 let me enable that and see if I can trigger it here Dec 19 12:07:11 stintel: how to properly flash the usd card with the image? I noticed the build generates tar.gz files. the wiki mentiones some other file Dec 19 12:07:34 xback: zcat factory.gz | dd of=/dev/mmcblk0 bs=2M Dec 19 12:07:39 something liek that Dec 19 12:08:23 ill give it a try :) can dd if=/factory.gz be also used? Dec 19 12:08:36 (iso zcat) Dec 19 12:09:21 no. it needs to be decompressed Dec 19 12:09:35 ok. thanks! Dec 19 12:09:37 gunzip factory.gz ; dd if=factory of= .. Dec 19 12:09:48 but no zcat ? Dec 19 12:10:03 the only "card reader" I have here is my cns3xxx board :p Dec 19 12:10:09 ah :D Dec 19 12:10:24 Dell U2410++ Dec 19 12:10:55 too bad they're on the side of the monitor so I cannot use the one on my right monitor as it's blocked by my left monitor :) Dec 19 12:11:07 but those are first world problems :P Dec 19 12:14:14 hm, actually ubnt posted gpl code as recently as a couple of weeks ago, and at least one of the vendors already publishes their code on github, so thats entirely on ubnt Dec 19 12:26:29 the number of supported kernel branches is getting pretty silly, heh Dec 19 12:26:46 5 lts, 2 stable, mainline Dec 19 12:28:56 xback: ack Dec 19 12:31:52 nbd: thanks Dec 19 12:32:20 stintel: goot new. got the old rpi model B running also. seems I was indeed doing something wrong with the DD thing Dec 19 12:32:25 good news* Dec 19 12:33:23 xback: yes, I want to do a final 17.01.7 before january 16th (which is when the old signing gpg key expires) Dec 19 12:33:28 xback: cool :) Dec 19 12:33:36 xback: with a 4.4 refresh, preferably Dec 19 12:35:21 danitool: yes Dec 19 12:36:06 jow: I bumped 17.01 a few days ago on request of the freifunk-berlin people Dec 19 12:36:15 I'll keep it up-to-date until the release then Dec 19 12:37:07 xback: that would be most appreciated :) Dec 19 12:45:03 Hauke: as expected, "can't reproduce, can't fix it" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88544 Dec 19 12:47:41 ynezz: what's the host system, amd ryzen bychance? Dec 19 12:48:53 only very few board vendors are upgrading their existing products to new silicon vendor SDKs some want to have the new features they want to be backported to very old versions Dec 19 12:49:19 ubnt is probably too small to really push realtek to do something Dec 19 12:50:04 as far as I can see thats their only realtek product, so yeah Dec 19 12:50:20 also its just a switch management interface, doubt they care Dec 19 12:50:51 KanjiMonster: nope, it's stable build host, 541 days uptime, debian 8, Intel(R) Xeon(R) CPU D-1521 and I'm using to build test everything from scratch usually, I don't remember hitting any of the gcc bugs for ages Dec 19 12:51:05 their other boards aren't so bad, cavium went to 4.9, mediatek did too Dec 19 12:51:19 not quite 4.14 but what you gonna do Dec 19 12:51:39 ynezz: strange. I remembered amd ryzen first batches being affected by random illegal instruction ICEs with gcc, that's why I'm asking Dec 19 12:51:57 but 4.9 has a longer EOL, so it makes sense for them Dec 19 12:53:03 sadly I have to use vendor sdks/kernels on some boards for now Dec 19 12:53:11 pain in the ass Dec 19 12:53:36 KanjiMonster: I think it's something in 4.19 what is causing it :) Dec 19 12:53:42 but that is entirely ubnt being assholes rather than the vendor Dec 19 12:55:16 when you download a firmware update which contains GPL code the vendor delivered you the GPL binary so they also have to provide you with the source code, you do not have to buy the device Dec 19 12:55:17 KanjiMonster: hm, no, the first one https://paste.ubuntu.com/p/yy7gsgYWrM/ is from build checking layerscape update to 4.14, but it's related to kernel headers though Dec 19 12:55:50 I think when you buy the device the company which sold you the device has to provide the GPL code Dec 19 12:55:55 Hauke: yeah they're starting to cite NDAs as an excuse (even though the code in question isn't under NDA) Dec 19 12:56:29 but also they haven't officially released the new firmware yet, so we'll see Dec 19 12:56:34 maybe they will provide it once its finalised Dec 19 12:57:00 theres no excuse for not releasing the older code though Dec 19 12:57:07 If you restrict the freedoms of the GPL you are breaking the GPL, if a NDA restricts it, it is breaking the GPL Dec 19 12:57:15 yup Dec 19 12:57:28 thats why they implement their NDA code in their own kmods Dec 19 12:57:48 which means I need their kernel code to be able to load them Dec 19 12:58:12 however the currently released firmware is 3.14 I think, far too old Dec 19 12:58:30 it's missing working f2fs for a start Dec 19 12:59:59 the "NDA" code is actually a switch already supported by swconfig and DSA, but they're just being difficult and doing all the setup in their binary kmods, instead of just describing it in the dts Dec 19 13:00:37 plus the cavium offload bits which are out of tree so aren't covered by GPL anyway Dec 19 13:01:09 ok, my missing chipidea thing from yesterday was from switching to a new devicetype in menuconfig. Dec 19 13:01:26 after using a config stub and make defconfig, I correctly got the chipidea kmod puleed in by default Dec 19 13:01:44 related to the "build for multiple devices" stuff. Dec 19 13:02:27 karlp: with build for multiple devices default package sets are forced, you can't forget them (but you also can't decide to not include them ;) Dec 19 13:03:53 so is it then safest to just explicitly add them to the DEVICE_PACKAGES set in the Device/blah file? Dec 19 13:04:33 hrm, it already is. Dec 19 13:04:59 I'm just gonna call this user error for now, instead of trying to fiddle that further. Dec 19 13:25:05 stintel: got it: Dec 19 13:25:14 [ 8.822957] kmodloader: loading kernel modules from /etc/modules.d/* Dec 19 13:25:16 [ 8.842547] jitterentropy: Initialization failed with host not compliant with requirements: 2 Dec 19 13:25:17 [ 8.861059] jitterentropy: Initialization failed with host not compliant with requirements: 2 Dec 19 13:30:33 xback: aha Dec 19 13:40:41 wigyori: I am currently making the sunxi target work with kernel 4.19 Dec 19 13:40:53 and also update the u-boot and ATF Dec 19 13:48:40 jow, some ppl are reporting on the forum that they can no longer select stock QCA firmware w/out editing makefiles. I think they should be able to freely select both. Was that done on purpose? Dec 19 14:01:11 greearb: I do not think this was done on purpose Dec 19 14:01:29 can ou post the link please Dec 19 14:01:34 *you Dec 19 14:01:36 https://forum.openwrt.org/t/why-the-switch-to-unstable-ath10k-ct/27258/12 Dec 19 14:01:48 maybe user error, I don't know Dec 19 14:01:58 oh Dec 19 14:02:02 ubnt posted gpl sources! Dec 19 14:02:11 hidden away in the comments on a beta thread Dec 19 14:02:25 they're on the site just not linked, interesting Dec 19 14:07:49 Hauke: ack - i've started doing that, but probably you'll have more time for it - need to clean up the riscv64 target now that's 4.19 is in Dec 19 14:08:54 and then there is the csky stuff, but given that it's quite limited in use, that'll probably stay out of tree for a while Dec 19 14:09:16 jwh: there's nothing interesting inside... Dec 19 14:09:19 wigyori: I am waiting for risc-v ;-) Dec 19 14:09:32 ynezz: the bits I need appear to be there :D Dec 19 14:09:34 which csky board do you have? Dec 19 14:10:10 jwh: ah, which bits? I was only checking XM/W sources and the important stuff was missing Dec 19 14:10:26 ER (cavium) bits Dec 19 14:10:34 ah, maybe that's diffrent, ok Dec 19 14:10:46 although cavim publish their kernel sources now, I need the UBNT modified sources Dec 19 14:11:00 cavium* Dec 19 14:11:16 what kernel version do they use? Dec 19 14:11:21 4.9.something Dec 19 14:11:34 nice Dec 19 14:11:36 not great but its better than 3.14 like it was Dec 19 14:11:47 gonna blame the excessive LTS for 4.9 Dec 19 14:11:51 or 2.6.32 like on XW/M :) Dec 19 14:11:56 heh Dec 19 14:12:07 they still use madwifi Dec 19 14:12:12 probably doesn't help Dec 19 14:13:01 Hauke: so at least there is one user already waiting for it (you) ;) Dec 19 14:13:19 Hauke: that's the small devboard from aliexpress - the one with two usb and an sdcard slot only Dec 19 14:14:03 4.9.79 Dec 19 14:14:07 close enough Dec 19 14:14:41 I'm not gonna even bother trying to rebase .146 onop of it Dec 19 14:14:42 ontop* Dec 19 14:21:06 wigyori: do the csky boards have enought ram? Dec 19 14:28:40 Hauke: 64m, enough to run our current base build :D Dec 19 14:29:52 if it fits in 4M flash :) Dec 19 14:30:27 ok thats good Dec 19 14:35:03 ynezz: sdcard Dec 19 14:35:17 ynezz: there is a 4m spi flash on it, but that's for the bootloader Dec 19 14:40:38 Hauke: can you look into the ath10k firmware selection thing? Dec 19 14:41:39 jow ok Dec 19 14:47:33 jow: hnyman already commented in the forum thread Dec 19 14:47:48 Hauke: just noticed Dec 19 14:48:00 I think it is a user error Dec 19 14:51:05 I am on my way to visit my parrents and only have sometimes a 2G connection ;-) Dec 19 15:01:09 that sounds like fun Dec 19 15:02:45 greearb: The latest version of ath10k-ct fails to compile in OpenWRT: https://paste.ubuntu.com/p/pbRcphMft4/ Dec 19 15:04:18 oops, will fix Dec 19 15:06:42 anyone happens to know the upstream git repo of iproute2 ? Dec 19 15:06:59 isn't it on kernel.org? Dec 19 15:07:09 git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git Dec 19 15:07:20 so schemminger indeed, thanks greearb_ Dec 19 15:07:38 https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/ ? Dec 19 15:07:46 theres also a -next Dec 19 15:07:49 hm Dec 19 15:08:00 also how do they communicate? via lkml? Dec 19 15:08:12 netdev@vger.kernel.org Dec 19 15:08:13 jow:yes via netdev mailing list Dec 19 15:08:21 phew, okay Dec 19 15:08:47 181k line kernel diff, only 16 .rej, not so bad (obviously may not work anyway :D) Dec 19 15:09:10 all bpf stuff, ug Dec 19 15:09:13 ugh Dec 19 15:09:16 mamarley, please try latest ath10k-ct repo now Dec 19 15:10:03 I ended up making my own openwrt fork so I could add my own backports kernel, and now cannot easily pull in latest code to compile/test..serves me right I guess Dec 19 15:10:21 tell me about it Dec 19 15:10:28 it's a pain in the ass :D Dec 19 15:11:04 if someone can be bribed to add a kernel makefile that pulls in a git tree (and no backports at all), I'd be happy to try it out Dec 19 15:11:37 ugh Dec 19 15:11:47 vendors really need to learn how to use versioning Dec 19 15:12:35 greearb: It compiles now, thanks! Dec 19 15:13:46 that should fix at least the log-spam bugs related to new ath10k-ct, I should have new FW builds available later today that fixes a few of the wave-2 crashes Dec 19 15:14:40 greearb: Will those build be just for wave-2 or are you doing wave-1 builds too? Dec 19 15:15:04 if I supply a custom kernel tree for openwrt to build, it won't attempt to apply any of its patches right? Dec 19 15:15:25 not sure I'll have any new wave-1 code Dec 19 15:16:12 jwh, I want to use my own (github) kernel, and I'd prefer to pull in patches to it instead of deal with openwrt's patch applying system Dec 19 15:16:41 thats kinda what I'm doing Dec 19 15:16:42 but it would require hacking openwrt to not use backports and so forth Dec 19 15:17:01 you can specify a custom kernel tree and it (I think) doesn't attempt to apply any patches but uses it as-is Dec 19 15:17:13 so you'll have to apply things like the cmdlien hack yourself Dec 19 15:17:16 cmdline* Dec 19 15:18:09 I haven't tried it, and don't have time right now to really poke at it, but I find the current mess very difficult to use for my particular wants. Dec 19 15:18:47 yeah I originally tried integrating it but it doesn't really work that well, custom tree works better Dec 19 15:22:30 pending-4.19 are things taht are on mailing lists for 4.19, but haven't merged yet right? Dec 19 15:22:36 and are expected to be upstream or near upstream? Dec 19 15:22:47 it's only the hacks-4.x dir that you really need to stress about if you've got your own tree? Dec 19 15:23:00 I believe so yes Dec 19 15:23:14 but honestly I never got the cmdline thing to work properly Dec 19 15:23:18 maybe I did it wrong Dec 19 15:23:37 301-mips? Dec 19 15:24:44 umm Dec 19 15:24:47 I think its generic actually Dec 19 15:24:52 yeah, but it' Dec 19 15:24:58 s still called 301-mips-fmdlineblah Dec 19 15:25:01 the one that does the cmdline magic during the image Dec 19 15:25:02 ah Dec 19 15:25:03 maybe Dec 19 15:25:19 dunno its been a while Dec 19 15:25:31 probably so it doesn't have to be in ath25/ath79/ramips/ar71xx/etc.... Dec 19 15:25:33 I abandoned that idea as I couldn't backport enough to 3.14 Dec 19 15:25:44 makes sense Dec 19 15:26:20 vendor sources: someone touched a file they didn't need to, accidentally left a tab in so patch got upset Dec 19 15:26:31 no other changes, just a rogue tab Dec 19 15:40:42 St0neHead: wow, 4.14 for brcm2708? congratulations Dec 19 15:40:46 stintel: wow, 4.14 for brcm2708? congratulations Dec 19 15:40:55 St0neHead: mis-autocomplete Dec 19 15:44:52 rmilecki: finally :D Dec 19 15:45:17 thanks to everybody here who assisted with that vague vmalloc problem :) Dec 19 15:57:49 stintel: on to 4.19 now? ;-) Dec 19 15:58:39 that's for after branching Dec 19 15:58:47 I would like to fix bluetooth on brcm2708 now Dec 19 15:59:00 and then rebase mesongx target on 4.19 Dec 19 16:08:31 what do I basicaly need to do to offer my spare computing cycles to buildbots ? Dec 19 16:08:49 I've tried to google the answer, wiki, but -ENOLUCK :) Dec 19 16:14:07 ynezz: basically setup a docker container and ask me for credentials so that I can join the slave Dec 19 16:16:29 jwh: yeah, people don't ever really understand why peoiple are anal on whitespace and unrelated changes until they've had to look after that sort of thing in practice :) Dec 19 16:16:53 heh Dec 19 16:17:14 well, I think I've managed to merge these ok, but I doubt it Dec 19 16:17:30 this happens if underpaid coders open kernel sources in eclipse Dec 19 16:17:32 git diff | patch does not produce the same result as diff -u orig curr Dec 19 16:17:41 ctrl-s, bam entire file reformatted Dec 19 16:17:44 ha Dec 19 16:17:58 the concept of git, history, reverts is unknown Dec 19 16:18:30 does eclipse even handle hving the kernel tree open? Dec 19 16:19:33 root@vm1:~/source/kernel# make ARCH=mips CROSS_COMPILE=/opt/cavium/bin/mips64-octeon-linux-gnu- Dec 19 16:19:36 scripts/kconfig/conf --silentoldconfig Kconfig Dec 19 16:19:37 we lets see :D Dec 19 16:19:42 well* Dec 19 16:19:53 I also once took a peak at a realtek sdk kernel Dec 19 16:20:10 is it as horrible as you'd expect? Dec 19 16:20:18 this was weird as well, thousands of changed files (usually just reformat or unrelated header comments) Dec 19 16:20:27 yeah Dec 19 16:20:33 thats normaly the case, vendors are just awful Dec 19 16:20:51 and an enormous diff spread over the entire kernel which looked like a crappy reinvention of netlink Dec 19 16:20:57 these days theres no excuse, they could easily rebase their changes on upstream kernel and deliver the entire repo to board makers Dec 19 16:21:10 so everyone has a working history etc Dec 19 16:21:12 major headthink change though Dec 19 16:21:16 oh, yeah Dec 19 16:21:19 for sure Dec 19 16:21:39 but at least try and make it easier for your customers, Dec 19 16:21:43 yeah but handing over a repo would imply having a repo Dec 19 16:21:52 which in turn requires competent developers Dec 19 16:22:38 https://github.com/Cavium-Open-Source-Distributions/OCTEON-SDK Dec 19 16:22:41 like that? :D Dec 19 16:22:58 competent in the sense of knows what a rebase it, can handle >1 branch at the same time, understands significance of locality, order and description of changes etc. Dec 19 16:23:12 (no source control, loads of unrelated files touched, no idea what version the tree really is as theres backports and all sorts of nonsense) Dec 19 16:23:40 I expect that is an exact copy of the one they use in house and deliver to their customers Dec 19 16:23:43 heh Dec 19 16:24:32 hm, this is compiing... Dec 19 16:24:33 can't be Dec 19 16:27:16 jow: any example? buildbot/buildbot-worker docker image would be enough? what about the volumes, I could imagine, that having dl/bin/{staging,build}_dir dirs out of docker would be better Dec 19 16:27:51 no way has this worked Dec 19 16:28:29 ooooook, it compiled Dec 19 16:33:09 ynezz: moemnt Dec 19 16:33:19 I don't need it now, don't worry Dec 19 16:33:32 ynezz: actually, I have to leave in a minute - can take a look at this tomorrow? Dec 19 16:33:39 +we Dec 19 16:33:57 sure, it's my todo for next month, don't worry Dec 19 16:34:17 I think I've used a custom dockerfile which uses a debian base recipe and then apt-get install the stuff I need Dec 19 16:34:39 buildbot builds use CONFIG_AUTOREMOVE and should never exceed 15-20G space usage Dec 19 16:35:28 ah, so it's always from scratch, no incremental builds? Dec 19 16:39:26 ha, I'm being trolled! x_tables: version magic '4.9.79-UBNT SMP mod_unload OCTEON 64BIT ' should be '4.9.146-UBNT SMP mod_unload OCTEON 64BIT ' Dec 19 16:42:39 ynezz: I am slowly converting to always from scratch, yes Dec 19 16:42:49 this wasn't feasible in the past due to lack of computing powert Dec 19 16:44:02 the buildroot has become more efficient too, even on the same hardware. Dec 19 16:49:20 the most time expensive part is building of the toolchain, where I can't see much difference between 32/64/96 cpu threads on GCE Dec 19 16:51:05 once you've toolchain you can max out all cpu threads and notice the number of cpu thread difference Dec 19 16:51:59 don't know if any other build system has this solved somehow yet :) Dec 19 16:55:22 ynezz: what could also provide a speedup is enabling ccache. but no idea tbh why it's currently disabled by default Dec 19 16:55:54 ynezz: for fun, ill start 2 identical builds tomorrow. 1 with ccache enabled and 1 with it disabled Dec 19 16:56:27 my ccache here has a 50% hit rate, 4.4gig cache size Dec 19 16:56:39 that's on a lot of rebuilds though, not fresh starts Dec 19 16:56:54 I wonder what the impact is on a fresh run Dec 19 17:01:04 I doubt, that ccache will help, as I was monitoring the builds in htop and the cpu utilization is very low during the build of the toolchain Dec 19 17:01:36 once it starts building target/kernel it's ideal Dec 19 17:01:59 but let's try it, thanks for the pointer Dec 19 17:02:35 I've disabled it once few years back as it was causing some weird build issues, maybe it's fixed Dec 19 17:03:11 to finish of, the biggest improvement here was just building in a ramdrive Dec 19 17:03:22 I'm doing that by default Dec 19 17:03:30 it easily shaved off 20~ comparing to ssd's Dec 19 17:04:21 biggest speedup for me is turening off SDK/IB/Toolchain pacakging :) Dec 19 17:04:44 I rather don't build them :) Dec 19 17:05:18 well yeah, that's what I mean Dec 19 17:05:20 ah yes. that one is still single threaded as multithread didn't create reproducable binaries iirc Dec 19 17:06:43 I understand that if you offer those images for public, but for buildtesting stuff I don't care much about it, as I don't even use those binaries Dec 19 17:07:39 ohhh, so the mediatek sdk is 4.14.54 Dec 19 17:07:42 but still the packaging could be background process and the rest of the cores could be busy with other stuff Dec 19 17:07:42 not bad, not bad Dec 19 17:08:00 nice Dec 19 17:09:09 cya all tomorrow xx Dec 19 17:09:54 root@vm1:~/erx/source/kernel# ls extensions/ Dec 19 17:09:55 libxt_FLOWOFFLOAD.c Dec 19 17:09:56 ha Dec 19 17:10:30 I need to get a new usb uart adapter Dec 19 17:10:36 I can't have killed 2 er-x boxes Dec 19 17:11:05 but they are *really* sensitive to ESD it seems, so its possibly Dec 19 17:11:06 possible Dec 19 17:11:58 hm, I'm experiencing same just with UBNT hardware :) Weird grounding and UART issues Dec 19 17:12:16 I killed my first er-x just by connecting the uart pins Dec 19 17:12:27 maybe it's because of the PoE? Dec 19 17:12:34 hm possibly Dec 19 17:12:56 they suck for not including an rj45 console port Dec 19 17:12:59 heh Dec 19 17:13:14 who do they think they are? mikrotik? Dec 19 17:13:26 3.5" audiojack ftw! Dec 19 17:13:29 lol Dec 19 17:13:39 its about time we got universal micro usb consoles Dec 19 17:13:50 with jtags, right Dec 19 17:13:58 jtag can stay inside Dec 19 17:14:16 but at least the serial console should be micro usb so we don't need adapters or breakout boards Dec 19 17:31:45 so I get no output at all if I connect all 3, but if I leave tx on its own I get garbled output :D Dec 19 17:32:34 think this adapter is busted Dec 19 17:33:18 jwh: gadget mode is awesome. Dec 19 17:33:44 g_cdc for getting a console _and_ a usb ethernet adapter Dec 19 17:34:25 so much nicer than these usb "consoles" that are just an onboard usb2serial chip connected to the uart0 pins Dec 19 17:39:17 hm guess not, I killed another er-x, adapter is fine on my dm200 Dec 19 17:39:27 these boards are so badly designed if they're that sensitive Dec 19 17:39:31 karlp: yeah Dec 19 17:39:52 but I'd settle for aa usb2serial Dec 19 17:39:59 at least I wouldn't keep killing boards Dec 19 17:40:04 the annoying thing is... it boots Dec 19 17:40:10 it gets link at least Dec 19 17:40:13 but theres no output Dec 19 17:40:39 but I seem to recal I had some utter nonsense at least with this adaptr, where the box wouldn't boot properly if I had uart attached Dec 19 17:40:53 yeah, there's a few like that. Dec 19 17:40:56 netgear were known for that. Dec 19 17:41:07 build #648 of sunxi/cortexa7 is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/sunxi%2Fcortexa7/builds/648 blamelist: Tony Ambardar , Kevin Darbyshire-Bryant , Jo-Philipp Wich , Yorkie Liu Dec 19 17:41:10 shitty pcb design, or shitty soc Dec 19 17:41:11 eithr or Dec 19 17:41:19 tis mediatek after all Dec 19 17:42:12 I think it was actually intended as active prevention. Dec 19 17:42:17 oh Dec 19 17:42:23 this isn't, ubnt don't do that Dec 19 17:42:26 this is just crap design Dec 19 17:42:51 they're one of the few vendors that leave uart headers populated or have serial consoles Dec 19 17:43:05 welllll. Dec 19 17:43:19 I've got a board that had headers, but you still needed to modify them before it _worked_ Dec 19 17:43:20 but this is definitey a board design thing Dec 19 17:43:32 well thats just it, these boards *do* work Dec 19 17:43:36 once Dec 19 17:43:41 until you ground them Dec 19 17:43:43 then poof Dec 19 17:44:03 but others have success so I'm sure its either me or this adapter Dec 19 17:44:33 or I got a bad batch, or theres something different about the sfp model (it has poe stuff) Dec 19 17:46:30 example, my first er-x-sfp I knocked the wires by accident and that was it, died Dec 19 17:46:47 never booted again Dec 19 17:47:43 uart adapter has never worked since either, doesn't even show up Dec 19 18:42:32 build #241 of gemini/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/gemini%2Fgeneric/builds/241 Dec 19 19:11:17 blogic: looks like Art is now the boss of MIPS: https://globenewswire.com/news-release/2018/12/03/1661174/0/en/Wave-Computing-Appoints-Industry-Veteran-Art-Swift-As-President-of-its-Recently-Acquired-MIPS-Licensing-Business.html Dec 19 19:11:32 I do not have more information than this press release Dec 19 19:45:10 Hauke: well mor $$ for his account Dec 19 19:45:20 thats what its all about Dec 19 19:45:41 he is worse than kathy ... Dec 19 19:45:48 ooopss did i just say that ? :-) Dec 19 19:46:09 although kathy is a nice person, i must state that for the record Dec 19 20:15:12 oh thats nice of them, ubnt/mediatek 4.14 kernel already includes the openwrt cmdline hack lol Dec 19 20:18:41 jow: ping Dec 19 20:28:58 build #1161 of x86/geode is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/x86%2Fgeode/builds/1161 Dec 19 21:05:21 jwh: is this sdk from mediatek with kernel 4.14 based on OpenWrt? Dec 19 21:05:41 Hauke: unknown, I've only looked at the kernel Dec 19 21:05:53 the ubnt product is debian, though Dec 19 21:05:57 ok Dec 19 21:06:14 but I expect mediatek have an openwrt sdk like cavium and other vendors do Dec 19 21:06:28 maybe you could beat them over the head for non compliance Dec 19 21:08:18 I think all vendors expect braodcom have an OpenWrt based SDK Dec 19 21:09:00 :( Dec 19 21:18:20 Hauke: broadcom doesn't? don't many of their routers just run old openwrt anyway? Dec 19 21:20:01 jow: i have an mbedtls 2.14.1 bump ready for you for 18.06.2 if you'd like to test drive it. i just finished compiling my own 18.06.2 tree here and well be run-testing it as of tomorrow. compiles fine at least on ar71xx / mt7621 / x86/64 Dec 19 21:29:47 Borromini: I think [florian] is working on this, but I think they mostly use their own SDK Dec 19 21:30:29 Borromini: do you also have the fix for mbedtls, I committed a day later? it does not compile on old ARM CPUs any more Dec 19 21:31:04 Hauke: no, good catch. i will integrate that, thanks for the tip. Dec 19 21:33:56 Borromini: the NIH is strong at broadcom ;) Dec 19 21:34:58 KanjiMonster: is that an acronym for the dark side? i don't know NIH sorry :-( Dec 19 21:35:20 Not Invented Here Dec 19 21:35:30 oh Dec 19 21:35:33 hehehe Dec 19 21:35:46 costs money to develop your own stuff Dec 19 21:35:47 :D Dec 19 21:36:06 well the richest people tend to be the best thieves amirite... Dec 19 21:36:23 heh Dec 19 21:36:34 prety much Dec 19 21:36:54 ugh ... "not invented here" usually means the desire to implement stuff yourself instead of taken existing solutions (because you don't trust the work of others) Dec 19 21:36:56 argh where did my build vm go Dec 19 21:37:12 *taking Dec 19 21:37:32 its actually wandered off Dec 19 21:37:39 If I was making a router, I would just add OpenWRT support for it upstream and ship it with OpenWRT. :) Dec 19 21:37:55 but muh secrets! Dec 19 21:38:00 <[florian]> Hauke: not working on Wi-Fi SoCs, Cable Modem, yes Dec 19 21:38:05 because drivers give all the secrets away Dec 19 21:38:53 but you didn't pay for it! it can't be good! And what if there are bugs? Let's rather write our own thing specific to our needs Dec 19 21:39:11 lol Dec 19 21:39:59 <[florian]> KanjiMonster: you are good at this Dec 19 21:40:09 hehehe Dec 19 21:40:35 also think of all the new software patents we can file while creating our own thing Dec 19 21:41:19 build #162 of ramips/mt76x8 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ramips%2Fmt76x8/builds/162 Dec 19 21:41:30 the sweet smell of patents Dec 19 21:41:33 in the morning Dec 19 21:41:35 lol Dec 19 21:52:21 "sweet" Dec 19 21:54:35 capitalism is what keeps us warm at night Mister_X ;) Dec 19 22:04:20 Hauke: shall i send it in? i've incorporated your ARM fix. Dec 19 22:13:03 Borromini: I do not know how jow wants to handle it Dec 19 22:15:30 Hauke: i'll wait for jow then :) Dec 19 23:01:55 new firmware uploaded, names and sha-sums sent to the mailing list. And, I pushed ath10k-ct repo earlier, that fixes the log-spam reports. Dec 19 23:02:11 If someone can get this all upstream I would appreciate it Dec 19 23:31:52 greearb_: i wish you wouldn't overwrite those on your site :/ Dec 19 23:33:43 I didn't, name is different Dec 19 23:38:42 greearb_: ah, so we should be going by firmware-5-ct-full-community-12.bin-lede.002 and friends? Dec 19 23:39:04 any difference between those and the ones in the ath10k-fw-beta folders? Dec 19 23:39:06 the change from last commit would be 01 -> 02, and the hash changes Dec 19 23:39:13 all folder paths are the same Dec 19 23:39:27 I have to run, will check in later Dec 19 23:49:11 ty Dec 19 23:54:28 xback: btw, builds from scratch fails for me with ccache enabled Dec 19 23:57:08 has anyone packaged brcm_patchram_plus? Dec 20 00:00:04 (or is it not actually needed anymore?) Dec 20 00:51:08 * jwh sighs **** ENDING LOGGING AT Thu Dec 20 03:00:01 2018