**** BEGIN LOGGING AT Fri Nov 22 02:59:57 2019 Nov 22 04:45:50 stintel: I'll ping him Nov 22 05:16:27 greearb_: just some quick and early feedback, testing ath10k-ct 5.4 (https://patchwork.ozlabs.org/patch/1192455/ https://patchwork.ozlabs.org/patch/1192453/ https://patchwork.ozlabs.org/patch/1192454/) and ath10k-firmware-qca9984-ct-htt (nbg6817/ qca9984), I do get http://paste.debian.net/hidden/cfac08f9/ Nov 22 06:49:35 aparcar[m]: it looks like just some generic list of function names and their descriptions Nov 22 06:52:20 aparcar[m]: it's C, so everything apart from exit(0); is potentialy dangerous :p Nov 22 07:00:33 aparcar[m]: anyway, I would like to integrate Coverity scan as next static analyzer check into the CI native pipeline Nov 22 08:01:33 ynezz: sure I can integrate that. could you promote my coverity account or send me an api token? Nov 22 08:04:51 done Nov 22 08:07:29 thanks Nov 22 08:07:36 btw this triple openwrt is a bit awkward isn't it? https://gitlab.com/openwrt/openwrt/openwrt Nov 22 08:11:36 aparcar[m]: i kinda have to agree Nov 22 08:13:24 aparcar[m]: it's just current gitweb to GitLab mapping, on self-hosted GitLab it would be https://code.openwrt.org/openwrt/openwrt Nov 22 08:13:58 openwrt group/namespace, openwrt sub-group, openwrt repository Nov 22 08:14:59 its done this way for some reason, I've asked about it and keeping current gitweb structure was prefered Nov 22 08:16:44 aparcar[m]: BTW while talking about that Coverity scan CI integration, I was actually talking about openwrt-ci pipeline Nov 22 08:17:32 aparcar[m]: where every C project could upload coverity scan report after push to master branch Nov 22 08:18:06 aparcar[m]: and do the same periodically once a week in order to get possibly Coverity updates/improvements/new checks Nov 22 08:19:44 but this scheduled checks seems like PITA on GitLab as you can't define them in .gitlab-ci.yml, so we would probably need to create another Python script and setup it via API perhaps Nov 22 08:23:16 ynezz: for the periodic thing, maybe configure the buildbot farm to make every Nth build a coverity-enabled one? Nov 22 08:24:08 would have the advantage of not doing it if nothing changed Nov 22 08:25:44 coverity scan inside the CI after commit to master would be the fastest feedback loop Nov 22 08:26:42 periodic builds makes sense in order to get updates from coverity as I guess, that they include new checks, improve the old ones etc. Nov 22 08:27:12 and I guess, that the analysis is much easier on the single C project repo then on the complete OpenWrt build Nov 22 08:27:27 ok Nov 22 08:27:29 maybe I'm wrong Nov 22 08:28:09 there is quite a lot of things to consider and investigate, thats why it's on my TODO list Nov 22 08:28:15 Hauke: can you give a short overview what that mac80211 bump for 19.07 would entail? Does it fix known issues? Nov 22 08:31:06 ynezz: can you give me a quick idea of coverity? It's a tool you run over a repo and it spits out the issues? Nov 22 08:32:01 aparcar[m]: no, you build project with it, then upload the artifacts to coverity for analysis Nov 22 08:32:03 aparcar[m]: its a compiler wrapper which collects information during the compile process. That information is then uploaded to Coverity for offline static code analysis Nov 22 08:32:43 actually that buildbot might be a better fit for periodic coverity builds, we could simply build just all C projects at once, every day Nov 22 08:32:48 similar to the llvm/clang stuff used by ynezz, but a bit older and more mature Nov 22 08:32:50 sounds like we want to integrate coverity into the sdk and then use the modified sdks within the ci? Nov 22 08:32:59 no Nov 22 08:33:15 shrug Nov 22 08:33:26 check https://www.synopsys.com/blogs/software-security/integrating-coverity-scan-with-gitlab-ci/ Nov 22 08:33:36 aparcar[m]: you don't need modified SDKs, iirc a careful setup of environment variables should be enough Nov 22 08:34:01 cov-analysis-linux64-*/bin/cov-build --dir cov-int make -j4 Nov 22 08:34:04 thats all about it Nov 22 08:34:20 ah right, it was wrapping make even Nov 22 08:34:32 its been too long that I used it Nov 22 08:37:31 well thats sounds pretty easy to build. cool Nov 22 08:38:14 if we go the buildbot route, it might be nice to add important 3rd party components we use/patch as well, like busybox, hostapd, dropbear Nov 22 08:38:54 ynezz: what do you think is better? I can integrate it into buildbot but it appears more elegant to add it to openwrt-ci Nov 22 08:39:03 so even PRs are checked... Nov 22 08:39:11 no, you can't check PRs Nov 22 08:39:55 a) there is a usage limit b) you don't get immediate yes/no feedback Nov 22 08:42:56 so buildbot it is Nov 22 08:43:15 714MB... thats quite a big wrapper Nov 22 08:43:24 oh Nov 22 08:44:57 indeed, daily buildbot builds makes more sense Nov 22 08:45:37 aparcar[m]: cool Nov 22 08:45:52 mornin' folks Nov 22 08:46:26 60fb4c92b6b0d1582d31e02167b90b424185f3a2 is the first bad commit Nov 22 08:47:22 ynezz: uhm how do I build just fwtool? package/fwtool fails Nov 22 08:47:44 make package/fwtool/compile ? Nov 22 08:49:35 okay I'll send reports in a bit Nov 22 08:51:27 jow: what do you think of this profile approach for the buildbot? Nov 22 08:51:36 or, did you heard about it yet? Nov 22 08:51:42 *hear Nov 22 08:53:41 ynezz: do we want coverity for every target? Nov 22 08:57:21 do they support it? Nov 22 08:58:28 not sure. I'll try that in a minute Nov 22 08:58:49 we dont want coverity for every target, maybe just a representative selection Nov 22 08:59:03 big/little endian, 32/64 bit Nov 22 09:00:40 they might be able to spot those issues anyway Nov 22 09:01:24 Okay I'll look into an integration Nov 22 09:01:25 Build successfully submitted. Nov 22 09:01:32 so where does this submission pop up? Nov 22 09:02:48 I planned to discuss this with lynxis as he has probably prepared the current coverity setup Nov 22 09:03:06 I'm not able to use that coverity web interface, sorry Nov 22 09:04:18 me neither, does it require != firefox? Nov 22 09:04:43 its more UI/UX issue Nov 22 09:06:47 it seems like it's not loading anything... Nov 22 09:07:15 ynezz: how do you read the reports then? Nov 22 09:09:17 aparcar[m]: I had to disable ublock for it to work Nov 22 09:09:22 loads in firefox here Nov 22 09:15:30 * aparcar[m] uploaded an image: image.png (66KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/blcnKgmCnYqvhPQECEWFPmVJ > Nov 22 09:15:48 jow: can you see this image? the report is all empty... Nov 22 09:19:51 okay well, looking at https://scan.coverity.com/projects/openwrt this result seems to be about right. Coverity does not seem to like single uploads Nov 22 09:23:36 stintel: hmmm Nov 22 09:28:20 aparcar[m]: yeah, had that too, but toggling the report a few times made the list show up Nov 22 09:40:36 ynezz: did you made a coverity test with fstools and submitted that? Nov 22 09:43:21 nope, probably blogic Nov 22 09:44:17 it's me Nov 22 09:44:41 to me it seems as uploading the fstools only result to the same project wiped all other issues Nov 22 09:44:53 yea that's what I wrote ealrier Nov 22 09:45:09 oh connectivity issues may prevented the message... Nov 22 09:45:17 So all problems fixed :-) Nov 22 09:45:21 :D Nov 22 09:45:41 ldir: indeed. 6,423 total defects. 6,423 fixed. Nov 22 09:45:50 0 outstanding, 0 new Nov 22 09:45:55 so I suggest I setup the buildbot to run daily on x86/64 and sub a single big report Nov 22 09:45:58 Excellent work guys :-) Nov 22 09:46:09 this could even filter out the kernel stuff Nov 22 09:46:50 or just use every n-th x86 build as coverity build as jow suggested previously Nov 22 09:48:17 keep in mind the kernel is not clean, we patch it... ideally those patches don't introduce problems. Nov 22 09:49:07 * andy2244 morning, i need a quick hint, why do i keep getting a null object on this code? I try to get a bins version info, but the fs.exec seems to fail? Nov 22 09:49:09 load: function() { Nov 22 09:49:09 return Promise.all([ Nov 22 09:49:09 L.resolveDefault(fs.exec('/usr/sbin/smbd', ['-V']), null), Nov 22 09:49:09 ]); Nov 22 09:49:28 aparcar[m]: did you setup an ACL allowing exec access for smbd ? Nov 22 09:49:31 sorry, andy2244 Nov 22 09:50:00 the gift that keeps giving jow :) Nov 22 09:50:10 ah thanks did forget about the new acl stuff for the .js code and no i did not Nov 22 09:50:36 you need to restart rpcd and relogin afterwards Nov 22 09:50:50 ok thanks Nov 22 09:50:55 and I suggest to make a new acl file for luci-app-cifsd/samba Nov 22 09:51:07 basically copy luci-base.json and strip it down to what you need Nov 22 09:52:03 luci-app-cifsd already has one and i will make one for samba4 yes Nov 22 09:52:16 ynezz: wait but normally the x86 build only happends every 24 hours, doesn't it? Nov 22 09:53:47 btw a small issue came up, if we allow cifsd/samba4 to be installed at once, which technically works if you change the samba smb port, than we get two "network shares" entries in luci, so is this fine or do we want to rename them to "network shares (samba4)" and "network shares (cifsd)" ? i think its a fringe case so did not rename the entries? Nov 22 09:54:18 do we want people to be able to install both? Nov 22 09:54:43 i guess for testing speeds might be what we see at the beginning Nov 22 09:54:56 then you can just install one, test, uninstall, install next, test, done Nov 22 09:55:01 so installed but not running both at the same time Nov 22 09:55:09 I think being able to install both with cause problems and confusion Nov 22 09:55:19 s/with/will/ Nov 22 09:55:56 andy2244: for now I'd ignore that issue Nov 22 09:56:28 ok Nov 22 09:57:03 i will add the names/versions to the respective entries, so on the pages itself its clear what version is what Nov 22 09:57:53 I'd prefer to see 'network shares(cifsd/smbd)' myself but....who knows :-) Nov 22 09:58:09 karlp: what do you mean? Nov 22 09:58:12 ynezz: re: coverity? Nov 22 09:58:17 good morning Nov 22 09:58:26 I did manage to get the cifsd package to build under macos yesterday which was a 'yay' moment :-) Nov 22 10:00:09 lynxis: hi Nov 22 10:00:32 lynxis: morning :) if I understand it correctly, you're now running coverity builds somewhere on your infra, once a week, right? Nov 22 10:00:35 oh, having the fs module available, but not usable out of the box is going to keep being fun for people. we used to run things in the controller and put the results into the template context, but now the "same" method would be writing rpcd plugins for everything, Nov 22 10:00:50 and the fs module is so appealing, it's _right there_ but you can't use it without doing more Nov 22 10:01:28 yes, but I can live with that Nov 22 10:01:39 yeah, I mena, it's the right choice, Nov 22 10:01:43 but it's going to keep coming up Nov 22 10:01:53 lynxis: we're thinking, that it would be nice to move this somewhere under openwrt infra and build it more frequently in order to have faster feedback loop Nov 22 10:02:32 karlp: jow - document it, make it 'google-able' - direct people to the documentation Nov 22 10:02:34 ynezz: correct. the job is defined https://code.fe80.eu/openwrt/openwrt-ci/blob/master/jenkins-jobs/coverity.yml and executed here https://jenkins.fe80.eu/job/openwrt-coverity-build/ Nov 22 10:03:25 there is also an ansible playbook which creates the dependencies for the job (coverity tool chain) Nov 22 10:04:22 Hauke: no, I'm running IBSS on the interfaces. Currently making a setup with 4 wlan interfaces to check it using valgrind Nov 22 10:04:25 lynxis: sidenode, pushing a single report flushes all other information, which I just did. Could you trigger a build manually please? Nov 22 10:05:40 aparcar[m]: i'll try. i'm not sure if this is possible. there are coverity limits based on the size of the project. we're quite big meaning we're only allowed to push something around 2-3 times a week. Nov 22 10:06:30 aparcar[m]: triggered, but will take 6h. Nov 22 10:06:42 thanks Nov 22 10:07:39 lynxis: if take out the kernel from the scan, we might be fine with the limits, I mean we could build 7 times a week at least, right? Nov 22 10:08:36 lynxis: or create separate openwrt-kernel project for that purpose and build just this once a week Nov 22 10:08:49 ynezz: oh. they seems to increased the limit :) Nov 22 10:09:35 lynxis: what are the limits now? Nov 22 10:09:57 aparcar[m]: 7/week at least. I don't know how many lines we have right now Nov 22 10:10:18 I would like to see hostpad, busybox, dropbear added to the mix as well Nov 22 10:10:42 aren't they build by default as well? Nov 22 10:11:50 hm, maybe I'm blind (or UI issue) Nov 22 10:12:01 aparcar[m]: ynezz: if you like, you could also move the repo to github. Nov 22 10:12:09 take a look at PACKAGES in https://code.fe80.eu/openwrt/openwrt-ci/blob/master/jenkins-jobs/coverity.sh Nov 22 10:13:58 lynxis: no need for github, if I understand it correctly it should be doable within (merged into) https://git.openwrt.org/?p=buildbot.git Nov 22 10:14:02 I'd prefer to integrate this directly in buildbot and then also add all packages from base Nov 22 10:15:00 all packages from base is probably nonsense, I would focus on our C projects + services exposed to network by default for the start :) Nov 22 10:15:15 once it's down to 0 issues, we could add more :p Nov 22 10:15:34 jow: thanks with read + [ "exec" ] it works now, get a hang of the new .js stuff now, looks kinda nice to use Nov 22 10:16:14 aparcar[m]: we have to wait till tomorrow. Next submission permitted on or after 2019-Nov-23 7:59 AM UTC Nov 22 10:16:37 lynxis: ack Nov 22 10:17:15 aparcar[m]: lynxis: what about staging the cov-build outputs on a server (e.g. rsync share) and then have a cronjob somewhere that submits the latest file from there every 24 hours (or less) Nov 22 10:17:23 ynezz: can you create a list for me? Nov 22 10:17:29 this way we can keep the buildbot logic simple and do not have to worry about rate limiting there Nov 22 10:17:45 jow: is it possible to merge the output? Nov 22 10:17:49 jow: before we only uploaded once a week :) Nov 22 10:18:16 aparcar[m]: I don't think so, I'd simply overwrite the previous one, even if it hasn't been submitted yet Nov 22 10:18:50 jow: okay I though different projects build individually and the reports are merged Nov 22 10:19:36 ah you mean merging fstools, hostapd, etc. ? Nov 22 10:20:01 creating the cov-int data on every commit, merge it, upload it once a day Nov 22 10:21:27 * ldir just spots a bug in dnsmasq.init - makes it more secure ironically Nov 22 10:22:42 aparcar[m]: new list = merge current list, add new C projects (fwtool, urngd), add services exposed to network by default, so probably busybox, hostapd, dropbear Nov 22 10:23:39 aparcar[m]: good enough for a start in buildbot.git, anyone can then add more via standard patch submission Nov 22 10:24:42 jow: do you have any time soon to evaluate a bit the buildbot patches I created lately? Nov 22 10:24:47 jow: I'll explain later - just getting on/off trains/underground etc Nov 22 10:26:02 aparcar[m]: hopefully next week Nov 22 10:26:14 nice Nov 22 10:30:55 aparcar[m]: how is your blogpost about reproducible builds and openwrt? Nov 22 10:31:15 lynxis: uh right. what blog to use again? Nov 22 10:31:23 I can just write something up in markdown Nov 22 10:32:10 aparcar[m]: i'm using pelican, which is a static html renderer. Nov 22 10:32:22 you got a blog? Nov 22 10:33:00 hah I was in the process of converting my drupal blog to pelican Nov 22 10:33:06 totally forgot about that Nov 22 10:34:18 * stintel puts it on the whiteboard Nov 22 10:34:58 lynxis: I'll try to write something tomorrow Nov 22 10:35:53 jow: there seems to be a prpl build cluster we can use for buildbot testing. As they currently only build single profiles there is plenty of cpu for openwrt.git;master Nov 22 10:39:55 aparcar[m]: just in case it fits your needs. I would love to see ansible playbooks for our buildbot setup including docs how to recreate them :) Nov 22 10:40:31 aparcar[m]: https://lunarius.fe80.eu/blog/ Nov 22 10:40:49 I updated the docker seutp so it is pretty simple. jow got some ansible stuff he may share with me so I can publish them in a way Nov 22 11:18:54 jow: how do i translate something like this to a luci/js fs.exec call? Do i need to set acl's also for grep/awk or do i need to-do the parsing in js? Nov 22 11:18:55 cifsd -h 2>&1 | grep version | awk '{print $4,$5}' Nov 22 11:19:32 can you pastebin the cifsd -h output? Nov 22 11:20:13 https://www.irccloud.com/pastebin/8bEx1l5G/ Nov 22 11:20:36 i need the 2>&1, since there is no -h/-v option atm and its actually the error output Nov 22 11:22:28 if its too complicated, i can skip this for now and wait until they have added a proper -V option Nov 22 11:23:05 L.resolveDefault(fs.exec("cifsd", ["-h"]), {}).then(function(res) { return L.toArray((res.stderr || '').match(/version : (\S+ \S+)/))[1] }) Nov 22 11:23:43 ah cool thanks, sorry i'm not a web guy so have only basic javascript skills Nov 22 11:31:01 stintel, o/ Nov 22 11:48:07 nitroshift: yo Nov 22 11:56:56 Hauke: currently testing your mac80211 bump for 19.07. will share the results later this afternoon Nov 22 12:22:17 jow: about rsync share for coverity: coverity builds takes a lot of time because of the wrapper. do you plan to build always withcoverity Nov 22 12:24:38 lynxis: earlier today we discussed about making every Nth buildbot run a coverity one Nov 22 12:25:12 something like if (build % 10 == 0) $make = "cov-build $make" Nov 22 12:25:55 it was just an idea though, to introduce some kind of sampling. I think doing it for every build is no realistic option Nov 22 12:41:27 it makes me wonder how much of that time is kernel, probably 90% ? Nov 22 13:02:11 hm, I'm observing a weird problem in ramips on 19.07 Nov 22 13:03:01 ramips/patches-4.14/0100-prom_fixes.patch Nov 22 13:03:15 why do we have there "OWRTDTB" section? Nov 22 13:03:57 isn't that ARC specific? Nov 22 13:04:36 generic/pending-4.14/332-arc-add-OWRTDTB-section.patch Nov 22 13:04:52 pepe2k: isn't OWRTDTB a dummy elf section we add so that we can patch a dtb into a binary kernel image? Nov 22 13:07:04 jow: checking why we don't use append-dtb Nov 22 13:07:18 pepe2k: the code in that patch looks to me as if it patches the kernel to read the dtb from this elf section unless "chosen" is passed by the loader Nov 22 13:07:55 maybe bootloader stupidity Nov 22 13:08:25 in master we have: KERNEL_DTB = kernel-bin | append-dtb | lzma Nov 22 13:08:33 19.07: KERNEL_DTB = kernel-bin | patch-dtb | lzma Nov 22 13:08:40 under ramips Nov 22 13:08:40 pepe2k: https://github.com/openwrt/openwrt/pull/2170 Nov 22 13:08:56 seems append-dtb instead of that seems the way to go Nov 22 13:09:16 yeah, likely just a case of a missing backport Nov 22 13:09:22 yes, looks like Nov 22 13:10:20 should we backport it? Nov 22 13:10:52 I'm really not sure if it's safe but so far, in master nobody complained about it Nov 22 13:12:51 I'd say go for it Nov 22 13:14:06 jow: ok, I can take care of it as I'm backporting some ramips devices atm anyway (so could run-time test it)... but how does it look with the rc2 schedule? today? Nov 22 13:15:12 pepe2k: jow: FYI: https://github.com/openwrt/openwrt/commit/7a8d3432c739c6ff038295176e8b6324e92fc116 Nov 22 13:15:36 ah, too late, same as in the PR ... Nov 22 13:16:16 adrianschmutzler: yes, that's the one Nov 22 13:16:36 pepe2k: seems I have to defer to Tuesday Nov 22 13:16:42 I don't think I'll make it today Nov 22 13:17:12 jow: ok, then I will backport/cherry-pick that one and send patch first to ml just in case Nov 22 13:21:12 adrianschmutzler: your last patch, is the problem related to partition names or offsets? Nov 22 13:21:26 ah, I see, also offsets Nov 22 13:21:27 offsets Nov 22 13:21:55 btw, that EEPROM vs. art could be unified Nov 22 13:22:02 I stupidly assumed offsets would be the same as for ath10k or similar Nov 22 13:23:25 they should be, I wouldn't be surprised there is mistake in cases where offsets are different... Nov 22 13:23:50 yes, but it looks like the phy0 address is still correct everywhere Nov 22 13:24:24 so, something in ath9k driver or elsewhere in phy setup is able to read from different locations Nov 22 13:25:45 the difference between EEPROM and art is ar71xx vs. ath79. I already unified most of the names in ath79 half a year ago, also having art consistently in lower case. Nov 22 13:25:55 cool Nov 22 13:26:26 We might still have some "caldata" somewhere, but ath79 should be relatively clean. Nov 22 13:27:37 but I just grepped, some of the ubnt still use EEPROM Nov 22 13:28:06 when I switch to master I will check that offsets Nov 22 13:29:58 thanks, would be interesting to finally understand this. Nov 22 13:31:37 It's particularly interesting that for some devices there seems to be no address in art at all, just this strange 0xa0bf. But still, phy0 gets the correct address Nov 22 13:31:50 "in art" -> "in caldata" Nov 22 13:34:23 concerning the unification/cleanup stuff, I'm just never sure whether this is actually desired or just annoying people Nov 22 13:54:09 IMO, at the time it's "why is this important, surely rhere's better things to be doing" but x time units later, it's "I'm sure glad yyy is all consistent so I can do this other "important" thing easily" Nov 22 13:54:19 so.... keep goin? :) Nov 22 13:55:04 consistency is great, especially if it's regarded as a copy'n'paste source later Nov 22 14:01:46 and it sets the precedent for future submissions Nov 22 16:24:26 hi Nov 22 16:26:35 Hello! I've developed and want to publish a LuCI application for yggdrasil package. Which repo should Pull Request go to? Nov 22 16:28:10 build #59 of ramips/rt3883 is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt3883/builds/59 blamelist: Koen Vandeputte Nov 22 16:28:18 yggdrasil package is in the github.com/openwrt/packages repo Nov 22 16:29:30 build #148 of ramips/mt7620 is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7620/builds/148 blamelist: Lech Perczak , Adrian Schmutzler , Koen Vandeputte , Hauke Mehrtens , Andrew Nov 22 16:29:30 Cameron Nov 22 16:34:25 seems like a new symbol `JZ4780 DMA support (DMA_JZ4780) [N/m/y/?] (NEW)` leaked in kernel: bump 4.14 to 4.14.155 Nov 22 16:35:03 zhoreeq: github.com/openwrt/luci Nov 22 16:38:11 hm, no, it doesn't touch ramips Nov 22 16:39:21 karlp thanks Nov 22 16:39:34 ah, yes, it's this one c7befe4de8b3b8695f4724702b823b9768526458 Nov 22 16:39:48 dmaengine: dma-jz4780: Don't depend on MACH_JZ4780 Nov 22 16:40:29 and ramips still is at 4.14 ... Nov 22 16:41:13 there is some PR for 4.19, right? Nov 22 16:41:37 there is Nov 22 16:41:59 it's mostly ready AFAIK Nov 22 16:42:18 https://github.com/openwrt/openwrt/pull/2385 Nov 22 16:51:53 build #146 of ramips/mt7621 is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7621/builds/146 blamelist: Lech Perczak , Adrian Schmutzler , Koen Vandeputte , Hauke Mehrtens , Andrew Nov 22 16:51:53 Cameron Nov 22 16:57:23 pkgadd, I'll check that I didn't drop the fix for that, and possibly there are other reasons for that bad rate reported...seems like I saw an upstream patch to fix similar problem. Nov 22 16:58:25 build #176 of ramips/rt305x is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt305x/builds/176 blamelist: Lech Perczak , Adrian Schmutzler , Koen Vandeputte , Hauke Mehrtens , Andrew Nov 22 16:58:25 Cameron Nov 22 16:59:56 does the blame just list _all_ changes since the last build? because this list changes only to ar71xx or ath79 target folder ... Nov 22 17:03:23 adrianschmutzler: all commit authors since last build afaik Nov 22 17:23:40 Hi all Nov 22 17:23:52 Is 17.07 EOL or not? Nov 22 17:24:17 I doing some Asterisk CVE patches and am wondering if I need to include 17.07 or not... Nov 22 17:25:11 it's effectively EOL Nov 22 17:25:21 17.01, that is Nov 22 17:26:38 one backport three days ago, the one before from Sept. 23 Nov 22 17:27:22 Mmh, ok, will do it anyway, should be able to handle it quickly. Nov 22 17:27:28 kernel 4.4.194 Nov 22 17:27:41 Maybe EOL will be announced once 19.07 comes out Nov 22 17:27:46 :) Thanks! Nov 22 17:29:39 do we require a formal vote to put 17.01 to EOL? Or will it be just like nobody pushes anymore, but there is no definite decision? Nov 22 17:30:41 micmac1: the build infrastructure is running yet, so package updates will get pushed to the binary repos Nov 22 17:30:57 Right Nov 22 17:30:58 the plan was indeed to mark it eol once 19.07 is finalised Nov 22 17:31:13 which also means discontinuing package updates Nov 22 17:31:14 That would be a load off, thanks Nov 22 17:31:45 ah, I see, already taken care off this topic Nov 22 17:32:58 meh... building on a ryzen 7, 16 threads... autotools still slow as hell Nov 22 17:34:11 you got problems Nov 22 17:34:36 Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz here Nov 22 17:34:49 Without ccache I'd have died already :) Nov 22 17:36:28 ;) Nov 22 17:40:34 is it correct the current qos-script/sqm are for the whole openwrt's download/upload bandwidth control, if I need set limits per IP on br-lan the only option will be manually writing tc-scripts correct? Nov 22 17:41:16 need restrict a few devices' bandwidth on the br-lan side Nov 22 17:43:02 * rr123_ wonders if iptables rate limit module will do it Nov 22 17:46:10 rr123_: correct Nov 22 17:47:48 jow: patch & PR submitted Nov 22 17:48:39 thanks. checking netem/iptables-ratelimit now Nov 22 18:02:10 jow: I take it cmake is faster than autotools? Nov 22 18:03:09 actually in terms of speed, there are several experiments to be ran Nov 22 18:03:37 including having cmake generate meson files instead of GNU make files Nov 22 18:04:01 mangix: if you factor out the time to build cmake itself then yes, it is multiple orders of magnitude faster Nov 22 18:04:44 the speed of the generated makefiles is "fast enough", the speed of the tests running before is absymal with autotools Nov 22 18:14:16 build #173 of ramips/mt76x8 is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt76x8/builds/173 blamelist: Lech Perczak , Adrian Schmutzler , Koen Vandeputte , Hauke Mehrtens , Andrew Nov 22 18:14:16 Cameron Nov 22 18:27:10 jow: with some projects like protobuf, the autotools makefile doesn't even allow building in parallel, so it's an improvement there Nov 22 18:28:40 jow: I am not aware that the mac80211 update in 19.07 or master fixes a reported problem, but some of the changes are looking like security fixes Nov 22 18:33:21 build #50 of ramips/rt288x is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/ramips%2Frt288x/builds/50 blamelist: Koen Vandeputte Nov 22 18:33:42 aparcar[m]: ynezz: we can only do a limited number of coverity scans per day depending on the code size Nov 22 18:35:29 mangix: sure, but at least for C code, the actual time spent compiling .c files into .o ones is dwarfed by the time spent in m4sh code ensuring that the shell is not one out of the sixties Nov 22 18:36:01 even if it cannot run in parallel Nov 22 18:36:11 I like mine sixties kernel, lean and fast and can be fixed Fonzie -style xD Nov 22 18:36:35 well... shell too.. but anyway.. sorry for the random bad joke Nov 22 18:38:41 aparcar[m]: we could try to register more coverity projects for procd, netifd, ... Nov 22 18:51:51 heh Nov 22 18:52:01 i like to live dangerously make -j Nov 22 19:10:22 build #48 of brcm63xx/generic is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/brcm63xx%2Fgeneric/builds/48 blamelist: Koen Vandeputte Nov 22 19:21:56 Hi, I updated my router to tplink archer c7 ac1750, did a custom build from 19.07-rc branch, the machine boots except wifi does not work Nov 22 19:22:07 archer c7 v5.0 EU that is Nov 22 19:23:07 the default ath10k driver with the -ct options seemed to have some trouble loading QCA988X board-2.bin firmware , there was only board.bin firmware in the /lib/firmware/ directory, so I guess this might be the problem Nov 22 19:23:28 so I switched to the regular "ath10k" driver and the non-ct and non-ct-htt firmware, but still no wifi Nov 22 19:23:36 the wlanX interfaces don't show up in ifconfig -a Nov 22 19:24:18 does that sound somehow familiar ? Nov 22 19:26:35 I had an archer c7 v4 and still running 18.06.4 Nov 22 19:27:07 rr123_: DTS or non-DTS configuration ? Nov 22 19:27:24 rr123_: I picked DT-based one, but maybe the conversion isn't complete yet ? Nov 22 19:27:54 i'm not actually sure, whatever the default it is Nov 22 19:28:09 did not see an option for me to choose dts/non-dts Nov 22 19:28:12 rr123_: do you have /proc/device-tree ? :) Nov 22 19:28:29 nope... Nov 22 19:28:57 OK, non-DT Nov 22 19:29:44 build #55 of ramips/rt288x is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt288x/builds/55 blamelist: Koen Vandeputte , Hans Dedecker , Jo-Philipp Wich Nov 22 19:34:55 Marex: this is clean install (from factory image) or sysupgrade? ar71xx or ath79? Nov 22 19:34:55 DT means ath79, non-DT means ar71xx Nov 22 19:35:30 no wonder, i think 18.06 even 19.07 are both ar71xx by default? Nov 22 19:35:35 at least 18.06 is Nov 22 19:35:57 19.07 has images for both Nov 22 19:36:10 I've used some pre 19.07-rc tree on my c7v5 (ath79) and it was working fine Nov 22 19:36:59 2155e94d4b8e5 is last time I tried 19.07 on my c7v5 Nov 22 19:37:40 sounded like he is using ar71xx anyway Nov 22 19:38:03 or did you test ar71xx there, too Nov 22 19:38:29 ynezz: clean install after updating the tplink firmware to latest Nov 22 19:39:02 Marex: did you build ar71xx or ath79? Nov 22 19:39:02 adrianschmutzler: I used the DT option first, now I'm building the non-DT Nov 22 19:39:49 I've my generous day today, I will quickly try with images from rc1 "release" at my C7v5 here Nov 22 19:41:55 adrianschmutzler: don't worry about it, I can try the commit ynezz mentioned next Nov 22 19:52:09 with ath79 19.07.0-rc1, I can connect to the standard AP both on 2.4 and 5 GHz Nov 22 19:52:35 (didn't check whether data goes through or anything else) Nov 22 19:53:14 Hauke: yea I'd separate all openwrt specific projects and integrate it directly in the CI. I don't see more than 28 commit per week to the smaller projects (Up to 28 builds per week, with a maximum of 4 builds per day, for projects with fewer than 100K lines of code ) Nov 22 19:56:53 greearb_: the station trying to connect (and causing the splash) was probably (I don't really have access to that device) BCM43684/ 4x4 802.11ax Nov 22 19:57:14 I haven't seen that with 802.11ac devices so far Nov 22 19:57:16 adrianschmutzler: I use it as AP Nov 22 19:57:23 adrianschmutzler: can you pastebin dmesg output ? Nov 22 19:57:34 adrianschmutzler: also, does wlanX show up in ifconfig -a ? Nov 22 19:58:47 I guess so, otherwise he wont be able to connect Nov 22 19:59:11 I already put the device to rest again Nov 22 19:59:35 just wanted to check that the build is working in general Nov 22 20:00:12 so, you could start from the release or ynezz' commit, build, and check whether it's working then Nov 22 20:09:22 all right, so with the non-DT configuration I at least get wlan1, which is supposed to be the 2.4 GHz radio Nov 22 20:09:44 the 5 GHz radio is not working Nov 22 20:10:14 maybe it's related to 'after updating the tplink firmware to latest' ? Nov 22 20:10:24 ynezz: how so ? Nov 22 20:10:30 ynezz: that's what the wiki suggested Nov 22 20:11:24 I don't know, just guesing, I've never done this before, but it's quite strange, that it doesnt work out of the box Nov 22 20:13:02 so you've flashed this one https://downloads.openwrt.org/releases/19.07-SNAPSHOT/targets/ath79/generic/openwrt-19.07-snapshot-r10720-538ca42dda-ath79-generic-tplink_archer-c7-v5-squashfs-sysupgrade.bin ? Nov 22 20:13:40 ynezz: I built one myself Nov 22 20:13:54 ynezz: very much with the default configuration Nov 22 20:17:53 Marex: http://paste.ubuntu.com/p/fxNwXDCPcH/ Nov 22 20:18:14 why is '/bin/tic' not installed with the libncurses package? Did this prevent it - https://github.com/openwrt/openwrt/pull/1233/commits/542f64d580235562770ab562de3aedddaf3ce826 ? Nov 22 20:18:54 root@OpenWrt:/# iwinfo | egrep '(wlan|GHz)' Nov 22 20:18:54 wlan0 ESSID: "OpenWrt" Nov 22 20:18:54 Mode: Master Channel: 36 (5.180 GHz) Nov 22 20:18:54 wlan1 ESSID: "OpenWrt" Nov 22 20:18:54 Mode: Master Channel: 11 (2.462 GHz) Nov 22 20:19:44 works for me Nov 22 20:20:19 ynezz: that's on the v4 or v5 ? Nov 22 20:20:41 that pastebin contains all the details Nov 22 20:20:44 v5 Nov 22 20:20:55 ynezz: sorry, missed that one Nov 22 20:23:03 ynezz: can I feed the openwrt-factory image to sysupgrade to do clean installation ? Nov 22 20:24:08 no, factory is used only via bootloader Nov 22 20:24:54 `sysupgrade -n` should be enough Nov 22 20:25:07 I've never flashed factory on my c7v5 Nov 22 20:25:12 ynezz: all right, lemme finish the build from the commit you mentioned and let's see Nov 22 20:25:25 just use prebuilt binaries first? Nov 22 20:25:44 then you can get the working commit/config and add the stuff you need to tweak Nov 22 20:26:54 I am building from a commit you suggested, so that should work, right ? Nov 22 20:27:06 http://paste.ubuntu.com/p/TmGWtPgDYj/ from archer-c7-v5_ar71xx-generic_OpenWrt-19.07-SNAPSHOT-r10720-538ca42dda_info.txt Nov 22 20:27:39 538ca42dda are both working for me as well now, latest 19.07-rc1 (almost -rc2) Nov 22 20:27:46 both ar71xx/ath79 Nov 22 20:28:55 OK, I will cancel and restart the build again Nov 22 20:28:58 going back to where I started Nov 22 20:33:00 it's some remote setup with VLANs or such, where you can't test prebuilt image? Nov 22 20:34:06 ynezz: nope, I just don't want to :) Nov 22 20:34:19 ynezz: but maybe I should Nov 22 20:52:42 it looks like there is a throughout problem with ath10k-ct on QCA9984, https://bugs.openwrt.org/index.php?do=details&task_id=2593 there are multiple reports in the Forum. Nov 22 20:53:49 I created a package with configuration but it doesn't show up below extra packages, even though I can find the symbol in menuconfig. https://bpaste.net/show/IQO4S Nov 22 20:54:18 depends on.... =n Nov 22 20:54:49 ah ok, I thought DEPENDS:= were package lists Nov 22 20:54:56 but they're actually symbols? Nov 22 20:55:46 ah … I need DEPENDS:=+... Nov 22 20:55:59 thx Nov 22 21:10:06 ynezz: yep, the ATH79 doesn't work at all, no wifi, nothing Nov 22 21:10:24 ynezz: what I wonder about is why there is no wlanX in ifconfig -a output Nov 22 21:10:40 are the openwrt scripts doing some magic stuff to bring the wifi up somehow ? Nov 22 21:13:39 build #49 of pistachio/generic is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/pistachio%2Fgeneric/builds/49 blamelist: Koen Vandeputte Nov 22 21:17:06 hexa-: yeah, + will autoselect it, without the plus it won't appear until it's selected Nov 22 21:34:08 ynezz: oh, it seems hostapd doesn't support SAE Nov 22 21:34:26 ynezz: which exactly hostapd package do I need to support that? there's like 5 different ones Nov 22 21:40:09 jow: I've enabled ccache on the host, initial run from empty cache had a hit rate of 13.30%, a 2nd run after that has a hit rate of 99.68% (!) Nov 22 21:40:51 jow: and make tools install is about 30% faster, make toolchain install almost 50% Nov 22 21:41:12 but this is while building the same target twice, cache size is 3.6GB Nov 22 21:41:52 well, doh, I should've looked at logread before Nov 22 21:42:06 hostapd-openssl is what I needed to get SAE going and thus also the wifi Nov 22 21:42:14 or -wolfssl Nov 22 21:42:16 missing wlanX in ifconfig -a confused me Nov 22 21:46:22 hmmm didn't know a single target needs that much disk space to build. it's using 42GB right now Nov 22 21:48:25 building on tmpfs might be tricky with _only_ 128GB RAM Nov 22 21:50:53 heh, even make package/compile is ~30% faster. I would expect enabling ccache on the host not to impact that Nov 22 21:59:38 so simply enabling ccache on the host reduced my build-deploy pipeline runtime from ~50m to ~37m, including waiting for sysupgrade on 2 raspberry pi 0w + the 2m it needs to be able to connect to wifi Nov 22 22:00:05 I like this result Nov 22 22:04:04 ynezz: thanks **** BEGIN LOGGING AT Fri Nov 22 22:21:56 2019 Nov 22 22:26:11 ynezz: RPi has HWRNG. I installed rng-tools and that fixes the painfully long wait time. now I noticed rngd init script has START=25. urngd has START=00. I think it makes sense to start rngd also even earlier, at least before network and things actually using crypto, like dropbear. I'm thinking of changing rngd to START=15 (dropbear=19 network=20). makes sense to you ? Nov 22 22:34:16 I would actually even suggest to move rng-tools from the packages feed to openwrt base, and add it to DEFAULT_PACKAGES for all targets that have a HWRNG Nov 22 22:34:56 (granted they have enough storage) Nov 22 22:54:07 I don't have recent experience with hwrng, but this kernel->rngd->kernel round trip doesnt make any sense to me Nov 22 22:54:39 hwrng should provide the entropy directly within the kernel Nov 22 22:57:15 it's quite sensitive content, so I dont see a reason why it should be leaked to the userspace if not necessary Nov 22 22:57:42 The thing in general (That I've taught myself to believe) is that linux kernel doesn't blindly want any one source for entropy, but can have multiple, and most importantly check the data somehow that it is good stuff Nov 22 22:58:00 not that I know does this really relate to yout wqoneringd Nov 22 22:58:06 wonderings* Nov 22 23:00:18 also, the hwrng is a thing or things in somewhere, it has no direct relation to kernel or generally OS gathering entropy Nov 22 23:00:52 I guess I can do an RFC patch to the ML Nov 22 23:03:54 stintel: I do like that proposal though Nov 22 23:44:47 So after all that 802.11ax talk the other day, I decided to install an Intel AX200 in my laptop. It actually has multiple queues! I have never seen a multiqueue WiFi adapter before… Nov 23 00:01:57 tried the same build on tmpfs now, with host ccache still enabled, again 2.5m faster, but due to the RAM usage I'll not be able to run >1 build simultaneously Nov 23 00:02:28 I'll just be happy with the ~13m speedup due to ccache :) Nov 23 00:09:39 now lets see what gives with -j80 instead of -j40 **** ENDING LOGGING AT Sat Nov 23 02:59:57 2019