**** BEGIN LOGGING AT Thu Dec 20 03:00:01 2018 Dec 20 05:55:57 morning Dec 20 05:59:33 wth, now iproute2 which links libelf also needs gettext... this is getting ridiculous Dec 20 08:05:19 morning guys Dec 20 08:05:57 i have a tp-link archer c5 v4.0 on my desk, currently not supported in openwrt Dec 20 08:06:18 wikidevi suggests it's using mt76 for soc, wifi and eth Dec 20 08:06:24 can this be ported? Dec 20 08:06:59 link to wikidevi page: https://wikidevi.com/wiki/TP-LINK_Archer_C5_v4.x Dec 20 08:12:26 it looks similar to c50 v1 except for the switch chip which is now a realtek 8367s Dec 20 08:16:55 jow: you're going to really flip out when you discover the dependency on systemd ;-) Dec 20 08:19:24 Happy holidays :) Dec 20 08:19:24 hmm, it looks rather more similar to c2 v1 Dec 20 08:55:44 morning all Dec 20 08:56:34 jow: in your commit for updating ath10k ct, is it correct that 2 files also changed but the hashes did not? https://git.openwrt.org/?p=openwrt/openwrt.git;a=blobdiff;f=package/firmware/ath10k-firmware/Makefile;h=72b0f540db25ca9da853d9784ad5485da1921efd;hp=185fcc074b183944e323e575df53679b5fd9df85;hb=c0248183a49a9830a4a2458e54e83fa8a3c646c9;hpb=de7ae9a0efeb4584c2166aaab070273fd7a262b7 Dec 20 08:57:19 nitroshift: Currently OpenWrt doesn't support that switch. Though you could find the source code of the realtek switch SDK in MT7622 U-boot and write a swconfig driver for it using that. Dec 20 08:57:45 ynezz: strange that it fails .. I've used ccache for a few years on OpenWrt now Dec 20 09:06:09 <__lore__> nbd: net-next will close today, I think the only commit not yet merged in wireless-drivers-next that would be important for 4.21 is https://patchwork.kernel.org/patch/10716551/ Dec 20 09:22:52 xback: yes, I checked multiple times Dec 20 09:27:51 gch981213, thanks Dec 20 09:28:49 gch981213, i found this: https://patchwork.ozlabs.org/patch/832150/ Dec 20 09:29:07 it adds unmanaged support for exactly this switch Dec 20 09:35:34 nitroshift: No, it doesn't add support for it at all. He said "unmanaged" because it's unsupported. I guess TP-LINK did some basic initialization in U-boot so that the switch acts as a normal 6 port GE switch in firmware. Dec 20 09:35:49 oh, i see Dec 20 09:42:44 gch981213, could this help? https://github.com/Kwan-young-hoo/ToPC/blob/master/mtk-openwrt-4.0.1.0/target/linux/mediatek/files/drivers/net/phy/rtk/Makefile Dec 20 09:45:41 nitroshift: Ah, I guess that should work with some minor changes. Dec 20 09:46:49 but it's not suitable for submitting to mainline OpenWrt since the rtl8367c directory includes too much unneeded code. Dec 20 09:58:23 Hauke: ping Dec 20 09:59:18 Hi any have a min to bump the mwlwifi driver? Dec 20 09:59:33 Tapper: sure Dec 20 10:00:19 latest is here: https://github.com/kaloz/mwlwifi/commit/c2c8244d8fea5d59762cb14438ded00bf6d5965c Dec 20 10:00:55 I mest up my github and have not sorted it out or I would of dun the pull my selff Dec 20 10:03:24 it's a shame the package maintainer doesn't do this. Dec 20 10:05:03 * Tapper agrees with ldir Dec 20 10:08:09 test build running... Dec 20 10:09:13 jow: my colleague just reported build breakage with elfutils Dec 20 10:09:14 https://pastebin.com/raw/iJLtsCJR Dec 20 10:09:42 this was using gcc 8.2.0. I'm retesting using gcc 7.4.0 currently Dec 20 10:10:10 yeah, its a gcc 8 specific issue Dec 20 10:10:14 7 works Dec 20 10:10:27 ok. thanks Dec 20 10:10:33 someone with access to gcc 8 should debug it Dec 20 10:10:50 I am getting slightly annoyed by this elfutils crap Dec 20 10:11:14 i'll take a look at it now, as my build is at this point anyway Dec 20 10:11:31 I also noticed that this tools defaulted to Y when it was added Dec 20 10:11:42 which tools? Dec 20 10:11:49 elfutils Dec 20 10:12:05 when restarting my build yesterday, I got notified of this new package. and the default selection was Yes Dec 20 10:12:15 yeah because tc needs it now Dec 20 10:12:41 ah ok. thanks for the info Dec 20 10:12:47 or rather I made it need it, otherwise iproute2 would break if libelf happens to be staged Dec 20 10:13:14 so I made the depdendency explicit as we'll need libelf anyway for tc ebpf support Dec 20 10:14:07 Tapper: mwlwifi bump will take a few mor minutes, have to build an mvebu toolchain first Dec 20 10:15:02 I'm tempted to bump musl libc to 1.1.20 in 18.06 Dec 20 10:15:21 since it is abi compatible I don't see a reason why not Dec 20 10:15:46 true Dec 20 10:16:21 it has been in master for a very long time now. and 18.06 also shares the same kernel. Dec 20 10:18:21 jow, i've tested it, running since yesterday Dec 20 10:18:59 on a couple of wrt3200acm's Dec 20 10:34:10 bumped Dec 20 10:38:21 thanks jow Dec 20 10:48:46 hmm, 13.5KB overall size increase for a standard luci distribution in master compared to 18.06 Dec 20 10:51:53 on the other hand its way more modular now... maybe I should 18.06 to use master luci instead Dec 20 10:53:33 please no, master luci is wildly incompatible with 1806 stuff :) Dec 20 10:54:45 yeah Dec 20 11:11:07 greearb: ping (and sorry for constantly pestering you) Dec 20 12:03:10 jow: pong Dec 20 12:17:48 Hauke: I was wondering about the mbedtls update and whether to backport it Dec 20 12:19:01 I'm more and more convinced that we should move the soversion into the package name to avoid unresolved symbols or other abi compat issues if we bump libraries Dec 20 12:19:38 e.g. libfoo.so.0 -> libfoo0, libbar.so.1.2 -> libbar, libbaz.so.2.3 -> libbaz2 Dec 20 12:20:26 doesn't help when upstreams aren't on it enough to properly manage so versions though Dec 20 12:22:10 the above would also mean that packages using those libs will always break when the basename is changed Dec 20 12:22:46 but I actually prefer that compared to silently recompile those packages with the same version and pkg revision, just against a newer library Dec 20 12:23:13 and for a package maintainer it should be as simple as changing DEPENDS:=+libfoo to DEPENDS:=+libfoo2 Dec 20 12:23:30 unless there's indeed nontrivial changes in which case the package requires rework anyway Dec 20 12:23:55 but yo uhave to change _every_ depending package, everywhere. Dec 20 12:24:12 I mean, it might help some cases, but it's a lot of churn. Dec 20 12:25:02 yes, but is required Dec 20 12:25:23 for example all packages need version updates for opkg to notice the need for upgrade Dec 20 12:25:50 jow: is the csstidy bump related to my email? Dec 20 12:26:00 in the past we already had to arbitrarily e.g. touch perl module makefiles to force a recompilation against a newer perlbase Dec 20 12:26:05 ldir: yes, it should solve the issue Dec 20 12:26:18 jow: will test :-) thanks Dec 20 12:27:22 karlp: I mean the work to bump all users can also be moved to the one doing the library bump Dec 20 12:27:40 this would maybe slow down the eagerness to chase bleeding edge all the time Dec 20 12:27:47 heh Dec 20 12:28:28 jow: I thought the ABI_VERSION for packages as used by OpenSSL is already there to combat the issue without having to introduce distinct package name Dec 20 12:28:43 KanjiMonster: problem is that this is not exposed to opkg Dec 20 12:28:52 opkg only has package names and versions to work with Dec 20 12:29:04 and usually our dependencies specify no version constraints Dec 20 12:29:34 plus dependant packages are not version-incremented when rebuilt against a newer lib Dec 20 12:29:40 currently it is not possible to have multiple versions of a package installed in parallel Dec 20 12:30:12 so when I e.g. opkg upgrade libmbedtls, then opkg does not know that libustream-mbedtls also needs to be upgraded Dec 20 12:30:29 for this specific case of mbedtls, I would suggest to move to the long term stable branch there they only provide security updates and do not change API version Dec 20 12:30:55 worse, libustream-mbedtls wil lbe silently rebuilt and the version in the repo will eventually require a newer libmbedtls but it will still have the same name and version, making it backwards incompatible as well Dec 20 12:31:27 that'd be the alternative, never do major bumps again Dec 20 12:31:49 but I fear we lack the manpower to really do that, especially when upstream abandoned older versions already Dec 20 12:31:57 I think we should differenciate master and the stable branches Dec 20 12:33:27 which in practice will lead to stable getting abandonned two days after release, master diverging Dec 20 12:34:53 but stable vs. master branch polcy discussions aside, the very same (opkg / binary repo) issues manifest in master snapshots as well Dec 20 12:35:37 opkg upgrade libmbedtls after an abi/soversion change will break all installed software using it Dec 20 12:35:52 and opkg upgrade libustream-mbedtls will have no effect since its the same version Dec 20 12:40:07 hmm yes putting the API version into the package dependecies make sense Dec 20 12:40:13 jow: confirm fixed :-) Dec 20 12:41:22 can we do it somehow automatically? Like we define PKG_API_VERSION=123 in mbedtls and dependend packages automatically get a dependecy to this API version? Dec 20 12:42:14 jow: dare I press you for your thoughts re tc-tiny v tc-full and the 14KB difference? Dec 20 12:42:38 so that you do not have to manually speicfy the API version in your package like ustreamssl-mbedtls, but this would be added automatically into the binary package Dec 20 12:42:44 s/API/ABI/ Dec 20 12:43:01 ldir: when I initially looked at it I thought we already have tc-full & tiny, but now that I learned that there's just tc, I'd say we stick to just that Dec 20 12:43:37 ts is not integarted by default, so I think it is ok Dec 20 12:44:56 Hauke: I was thinking about that, problem is that the version of the package using this libs needs to increment too. Usually a maintainer would change DEPENDS:=+libmbedtls to e.g. DEPENDS:=+libmbedtls2 and increment PKG_RELEASE Dec 20 12:45:43 I think it was Tony's way of doing the elfutils dependency. ok, let's just stick with tc then :-) Dec 20 12:46:07 Hauke: the only automatic alternative I can think of is to somehow integrate the highest change timestamp or a similar of all used libraries into the package version Dec 20 12:47:15 or, assuming that we simply use a datestamp for our ABI_VERSION tags (e.g. 20181220), appending the max() of all ABI_VERSION tags of all used libraries Dec 20 12:48:55 e.g. libustream-mbedtls_2018-07-30-23a3f283-1_x86_64.ipk would become libustream-mbedtls_2018-07-30-23a3f283-1~20181220_x86_64.ipk assuming that libmbedtls has ABI_VERSION:=20181220 Dec 20 12:49:24 the ABI_VERSION must not correspond to any upstream version, it just has to be increasing whenever a breaking change happens Dec 20 12:50:02 the version number now gets bigger, but I think this is better thank doing this manually Dec 20 12:50:42 manual changes only work on the reposetories which are under our control, not external ones Dec 20 12:51:28 can we combine this with the PKG_REVISION ? Dec 20 12:51:30 another, slightly less invasive approach would be the following (I didn't test that yet): Dec 20 12:52:23 - make sure that ABI_VERSION ends up in the version of the library package itself, e.g. libmbedtls_2.14.1-1_x86_64.ipk => libmbedtls_2.14.1-1~20181220_x86_64.ipk Dec 20 12:53:13 - emit version constrained dependencies for the packages using this library, e.g. DEPENDS:=+libmbedtls would become "Depends: libmbedtls (<= 2.14.1-1~20181220)" in opkg metadata Dec 20 12:53:42 at the very least this would prevent installing a newer libmbedtls as long as there's users of the old lib installed Dec 20 12:54:03 what I didn't yet check is if opkg is clever enough to check the repo for newer versions of dependant packages Dec 20 12:55:50 but when multiple packages depend on mbedtls I would update for example curl to the new version and this needs mebdtels with the new soname and ustreamssl-mbedtls still needs the old version Dec 20 12:55:56 but not sure if opkg would consider the repo version of e.g. libustream-mbedtls as update when it has the same name and version Dec 20 12:56:20 so when I update one of them opkg sould update everything Dec 20 12:56:23 Hauke: correct, but I'd assume opkg to simply upgrade anything Dec 20 12:56:41 as part of the conflict resultion Dec 20 12:56:45 ok Dec 20 12:56:54 but thats a hypthesis I didn't actually test Dec 20 12:57:26 and it's rather confusing since it leads to conditional compilation, with ipk artifacts having the same filename but possibly different contents Dec 20 12:57:58 so I'd rather go with the first proposed approach of appending the highest used ABI_VERSION to the version number after PKG_RELEASE Dec 20 12:58:17 13:51 < Hauke> can we combine this with the PKG_REVISION ? Dec 20 12:58:23 not sure what you mean with this? Dec 20 13:01:09 jow: we could integarte the PKG_RELEASE variable into the PKG_ABI_VERSION Dec 20 13:01:51 make the PKG_RELEASE also a timestamp and generate it over the own PKG_RELEASE and the PKG_ABI_VERSIONs of the dependecies Dec 20 13:02:29 to make the revison number smaller again Dec 20 13:03:36 hmm Dec 20 13:04:09 then we'll need to start enforcing datestamps as PKG_RELEASE value Dec 20 13:04:19 things like 1..N wouldn't work then anymore Dec 20 13:04:48 yes, we could add a new variable and convert the packages over a longer period Dec 20 13:05:14 we could define that both ABI_VERSION and PKG_RELEASE [or its successory] need to be datestamps in the format YYMMDD Dec 20 13:05:37 and that the stamp needs to correspond to the date when the change in packaging was made/comitted (unrelated to upstream versioning) Dec 20 13:05:48 then it'd work Dec 20 13:06:14 it would then look like libustream-mbedtls_2018-07-30-23a3f283~181220_x86_64.ipk Dec 20 13:06:18 or similar Dec 20 13:07:22 looks good Dec 20 13:08:05 I am also fine with keeping the PKG_RELEASE like now and keep it as an extra in the file name Dec 20 13:09:23 but what happens with stable branches, the master and the stable veesion could have the same file name, but the master version already has some additions and the PKG_RELEASE was incemented, but some library was added to both Dec 20 13:09:28 we could introduce PKG_DATE, and use MAX($PKG_DATE, $ABI_VERSIONs...) if it is defined, else use $PKG_REVISION~MAX($ABI_VERSIONs...) Dec 20 13:10:53 you mean so that both end up with the same stamp max value? Dec 20 13:11:00 yes Dec 20 13:11:14 becasue the dependecy was updated in both Dec 20 13:11:30 good point... well this already occasionally happens now in practise already Dec 20 13:11:41 is this a problem? Dec 20 13:12:13 only for people exchanging packages between master and stable repos. I consider them completely different realms here Dec 20 13:12:40 making the version super globablly unique would require us to inorperate the branch name / release number or similar Dec 20 13:12:41 ok Dec 20 13:12:51 since there also could be toolchain differences leading to different results Dec 20 13:12:58 ok makes sense Dec 20 13:13:33 most of this is just to avoid problems when "maintainers" don't pay attention to the dependent packages right? Dec 20 13:13:41 can we justmake maintainers do better jobs of testing? Dec 20 13:13:52 karlp: only partially Dec 20 13:14:17 karlp: the problem is that packages are silently rebuilt against newer libs with any maintainer intervention Dec 20 13:14:42 because of the action of the "upstream" maintainer. Dec 20 13:14:47 the resulting artifacts (therir filenames / metadata) do not reflect this though, so this dynamic library dependencies behind the scenes are totally opque to opkg Dec 20 13:15:01 which makes packages upgrades risky Dec 20 13:15:14 or library upgrades, rather Dec 20 13:15:54 karlp: one could argue that, but then we still need to handle the case when we deliberately upgrade a library with an abi breakage Dec 20 13:16:29 e.g. openssl 1.0 to openssl 1.1 switch Dec 20 13:17:03 or libevent 2.0.22 to 2.1.5 Dec 20 13:18:23 I can't imagine opening pull requests bumping the PKG_RELEASE of all libopenssl or libevent users Dec 20 13:19:32 anyhow, in a nutshell it boils down to two issues: Dec 20 13:20:33 - library dependencies in opkg do not express version contraints, so opkg presumes libopenssl 0.9.8 to be equal to 1.1.0 even if they clearly arent Dec 20 13:21:58 jow: you calculations for PKG_DATE look good Dec 20 13:22:16 - package version is not increased when recompiled against newer libraries so its not visible from the outside that package foobar now requires /usr/lib/libssl.so.1.1 instead of /usr/lib/libssl.so.0.9 Dec 20 13:27:14 btw, I recently discovered https://abi-laboratory.pro/index.php?view=timeline&l=libevent Dec 20 13:27:33 didn't yet check what needs to be done to submit our libraries Dec 20 13:27:44 but looks like a handy tool for library package maintainers Dec 20 13:28:07 that's exactly the same css/html that libwebsockets has, I suspect you can run the tool yourself? Dec 20 13:28:36 https://libwebsockets.org/abi/timeline/libwebsockets/index.html Dec 20 13:28:50 it has the "generated by...." stuff at the bottom Dec 20 13:29:07 nvm, so does abi-laboratory :) Dec 20 13:30:22 https://abi-laboratory.pro/index.php?view=sponsor is what it costs to run your libraries there :) Dec 20 13:32:37 this is only for one library and not for a distribution ;-) Dec 20 13:33:08 I suppose something similar can be hacked up by comparing objdump / nm output of the old and the new so Dec 20 13:33:31 we don't need fine grained reports about whether unsigned short was changed into unit16_t Dec 20 13:33:45 we do not care about added symbols either Dec 20 13:33:56 only about removed symbols and soname changes Dec 20 13:36:35 yes, but think the tools are open source so when we hack something together we can also use their tools ;-) Dec 20 13:39:23 jow: we also care about changed structs, especially if members in the middle get added/removed Dec 20 13:42:46 KanjiMonster: right, wouldn't have expected to be an issue with things like libevent but you never know... Dec 20 14:05:37 remember2.1 wasn't considered stable at that point Dec 20 14:52:06 movi, here Dec 20 14:53:15 greearb: seems by ps4pro can't talk connect, but there's nothing more that i see than hostapd messages. any idea how i can debug this further? Dec 20 14:53:18 *my Dec 20 14:54:57 movi, to what is it trying to connect? And, you need over-the-air capture to debug strange things probably Dec 20 15:00:15 9980, 5Ghz. looks like it's getting dhcp but then can pass no traffic Dec 20 15:00:46 other stations are fine, and making it run on ethernet works as well Dec 20 15:01:18 movi, does stock 9980 QCA firmware have the same problem? Dec 20 15:01:36 (and please test with ath10k-ct driver + stock FW to make sure it is firmware issue) Dec 20 15:01:43 nope, this used to work (i don't boot it up so often) Dec 20 15:04:56 greearb: the ath10k-ct-htt fw you sent is working well (2 days up with only 1 fw crash on phy0 last night) Dec 20 15:05:09 greearb: i just figured out i can force bands. works perfect on 2.4Ghz :/ Dec 20 15:06:04 greearb: do you want to see the details? in the now closed issue or open a new issue? Dec 20 15:08:57 nmrh, please open a new bug with that crash and put the chipset in the title if you can. Dec 20 15:09:19 how/why are you forcing bands? Dec 20 15:10:11 movi, maybe you have a different NIC on 2.4? Dec 20 15:15:31 greearb: what do you mean by thhat? Dec 20 15:16:09 i have 2x9980, one is 2.4 one is 5, both are bridged to lan. there should be no difference Dec 20 15:16:46 ok. On 5Ghz where it fails with CT FW, will it work with stock FW? Dec 20 15:17:43 ldir: please put your patch into accepted state in patchworks after you applied them Dec 20 15:18:04 Hauke: ooops! forgot about that Dec 20 15:21:07 greearb: about to find out, just need to get the stock fw somehow Dec 20 15:33:12 build #1116 of lantiq/xrx200 is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/lantiq%2Fxrx200/builds/1116 blamelist: Koen Vandeputte , Hans Dedecker , Kevin Darbyshire-Bryant , Jo-Philipp Wich Dec 20 15:33:28 Who's the lucky one .. Dec 20 15:33:41 oh bollox - what did I break? Dec 20 15:34:33 build #1125 of brcm2708/bcm2709 is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2709/builds/1125 blamelist: Koen Vandeputte , Hans Dedecker , Kevin Darbyshire-Bryant , Jo-Philipp Wich Dec 20 15:35:33 package/Makefile:107: recipe for target 'package/network/services/odhcpd/compile' failed Dec 20 15:35:35 make[1]: *** [package/network/services/odhcpd/compile] Error 2 Dec 20 15:35:36 make[1]: *** Waiting for unfinished jobs.... Dec 20 15:37:42 ???? well I definitely didn't touch odhcpd Dec 20 15:37:47 greearb: works fine with your driver and ath10k_pci 0000:01:00.0: firmware ver 10.4.1.00030-1 api 5 features no-p2p crc32 d2901e01 Dec 20 15:38:02 ldir: it's dedeckeh this round :) Dec 20 15:38:39 xback:let me check Dec 20 15:39:01 build #1113 of brcm2708/bcm2708 is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2708/builds/1113 blamelist: Koen Vandeputte , Hans Dedecker , Kevin Darbyshire-Bryant , Jo-Philipp Wich Dec 20 15:42:21 my browser locks up trying to search the log file! macbook dying Dec 20 15:47:56 movi, I'll build you a stock-ish version of my FW and if it works, then I can build you images to bisect with Dec 20 15:48:27 ha! I'm looking for a commit to odhcpd that I don't yet have 'cos I haven't done a git fetch ! Doh! That's why I was so confused...there hasn't been a change to odhcpd Dec 20 15:48:29 greearb_: sure. by the way is there a more convienient way to reload the firmware/driver than just rebooting? Dec 20 15:50:19 odhcpd- seems a bit suspicious Dec 20 15:50:23 copy it into place; rmmod ath10k_pci ath10k_core; modprobe ath10k_pci; # hope user-space deals with it Dec 20 15:50:52 ldir: xback: fixed now; sorry for the noise Dec 20 15:51:24 deleted by accident PKG_VERSION after testing the update Dec 20 15:51:30 lol - I'm just glad it wasn't me...this time :-) Dec 20 15:51:41 or more like.... yet Dec 20 15:51:45 dedeckeh: no problem :) Dec 20 15:59:38 build #1100 of octeon/generic is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/octeon%2Fgeneric/builds/1100 blamelist: Koen Vandeputte , Hans Dedecker , Kevin Darbyshire-Bryant , Jo-Philipp Wich Dec 20 16:05:10 build #706 of at91/sama5d3 is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d3/builds/706 blamelist: Koen Vandeputte , Hans Dedecker , Kevin Darbyshire-Bryant , Jo-Philipp Wich Dec 20 16:05:51 ldir: btw .. I bumped the musl patch again today Dec 20 16:06:21 xback: oh ok, that gives me something else to break :-) Dec 20 16:06:55 build #252 of at91/sama5d2 is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d2/builds/252 blamelist: Koen Vandeputte , Hans Dedecker , Kevin Darbyshire-Bryant , Jo-Philipp Wich Dec 20 16:07:10 build #253 of at91/sama5d4 is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d4/builds/253 blamelist: Koen Vandeputte , Hans Dedecker , Kevin Darbyshire-Bryant , Jo-Philipp Wich Dec 20 16:08:25 greearb_: i made a dedicated ap for it, so i won't have to reboot my main one every firmware. hit me up whenever Dec 20 16:09:03 xback: oh lordi I see you're playing with the package we dare not speak of... well not in front of jow at least :-) Dec 20 16:09:48 ldir: my colleague was playing with gcc 8.2.0 and this package breaks the build when using 8.2.0 Dec 20 16:10:04 checked the git and noticed the new version Dec 20 16:10:32 but I'm not pushing it .. I really don't want to be involved in this one Dec 20 16:11:00 You can take the patch and change owner to you if you like ;) Dec 20 16:11:07 Author* Dec 20 16:11:16 yeah well that's my fault 'cos I got keen and committed something I shouldn't have Dec 20 16:11:36 and that left chaos on the buildbots. Dec 20 16:12:09 and that made jow unhappy Dec 20 16:12:59 fwiw .. i voted so you can keep your push rights ;-) Dec 20 16:13:25 lol Dec 20 16:14:32 anyways .. last day at work is ending for this year. next kernel bump is scheduled for 07-Jan ;) Dec 20 16:14:45 xback: unlike brexit you can probably have another vote....so you can make the *correct* decision this time Dec 20 16:14:55 ldir: lol Dec 20 16:15:32 after the brexit you'll need to upload a certificate to the server every month ;-) Dec 20 16:17:02 lol - very wise - europe definitely needs to protect itself from stupidity Dec 20 16:18:28 ldir: so brexit was not the correct decision ? Dec 20 16:19:11 blogic: it depends who you speak to Dec 20 16:21:20 blogic: "I wish to apologise for my country's conduct over Brexit" ;-) To paraphrase a well known (to you at least) comedy sketch. Dec 20 16:22:20 * ldir goes back to wondering why this bus is late Dec 20 16:22:33 build #129 of samsung/s5pv210 is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/samsung%2Fs5pv210/builds/129 blamelist: Koen Vandeputte , Hans Dedecker , Kevin Darbyshire-Bryant , Jo-Philipp Wich Dec 20 17:30:10 * ldir wishes there was a way to get a buildbot to look at a staging tree to find out all the fallout before pushing stuff Dec 20 17:36:16 Hauke, I pushed new ath10k-ct, quietens some more ath10k log spam per Rober Marko's suggestion. Dec 20 17:38:09 build #649 of sunxi/cortexa7 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/sunxi%2Fcortexa7/builds/649 Dec 20 17:41:03 ugh i should have clarified my device. now i'm getting emails about this mysterious highmem device Dec 20 17:54:23 ldir: it will happen, eventually. But, so many other things to do first Dec 20 18:18:08 build #242 of gemini/generic is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/gemini%2Fgeneric/builds/242 blamelist: Koen Vandeputte , Hans Dedecker , Kevin Darbyshire-Bryant , Jo-Philipp Wich Dec 20 19:06:11 greearb_: do you want a github issue for the ps4 problem? Dec 20 19:08:55 movi_, yes please Dec 20 19:10:07 ldir: :-) Dec 20 19:10:19 ldir: would never have happened ... *cough* Dec 20 19:19:26 greearb_: done https://github.com/greearb/ath10k-ct/issues/50 Dec 20 20:40:59 hi guys. Dec 20 20:41:02 jow: ping :^) Dec 20 20:57:02 movi, I'm going to let my build script finish (which will take hours more), then can try to figure out why that 9980 0006 image failed Dec 20 21:14:40 build #1162 of at91/legacy is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Flegacy/builds/1162 blamelist: Daniel F. Dickinson , Koen Vandeputte , Christian Lamparter , Hans Dedecker , Kevin Dec 20 21:14:40 Darbyshire-Bryant , Jo-Philipp Wich Dec 20 22:10:19 greearb_: I am not at home the next few days and testing this could be a little bit hard, if someone wants to create a patch for ath10k-ct and test it it would be nice Dec 20 22:12:09 no worries, it can wait I think, or maybe someone other than me or you is interested :) Dec 20 22:48:43 build #1152 of mpc85xx/generic is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/mpc85xx%2Fgeneric/builds/1152 blamelist: Daniel F. Dickinson , Koen Vandeputte , Hans Dedecker , Jo-Philipp Wich , Christian Dec 20 22:48:43 Lamparter **** ENDING LOGGING AT Fri Dec 21 03:00:02 2018