**** BEGIN LOGGING AT Mon Nov 25 02:59:58 2019 Nov 25 07:15:09 SpaceRat: now I am Nov 25 07:15:23 morning Nov 25 07:15:52 tobleminer-tSYS: hi, I just took over yours https://patchwork.ozlabs.org/user/todo/openwrt/?series=78517 ("libubox: Enhance robustness of blobmsg parsing") and I'm wondering if you could rebase, add commit description to patch 3/3 and add some test case(s) with malformed blobs which would show the oob access Nov 25 07:17:34 grml Nov 25 07:17:42 10% discount on lenovo.com Nov 25 07:18:15 I just buy my TPs refurbished, never spent mpore than 220 euro for one :P Nov 25 07:18:24 lol Nov 25 07:18:26 tobleminer-tSYS: if you check out the latest libubox sources, there are already some unit tests Nov 25 07:18:34 jow: i want a P53 Nov 25 07:18:47 AND Nov 25 07:18:50 *drumroll* Nov 25 07:18:58 today is the day, xmas come early Nov 25 07:19:10 my fiber is getting put into the ground today :-D Nov 25 07:19:26 yay Nov 25 07:19:31 they need to dig 45m Nov 25 07:19:52 and apparently on friday the media convertor is getting installed Nov 25 07:25:34 blogic: that P53 looks quite bulky Nov 25 07:26:00 yes Nov 25 07:26:16 its a desktop in a laptop case Nov 25 07:26:34 I see Nov 25 07:33:26 are you getting the version with xeon as well? :p Nov 25 07:33:43 hehe Nov 25 07:33:45 no Nov 25 07:33:47 i7 Nov 25 07:34:02 i'd like the i9 but that is way to expensive Nov 25 07:34:27 right now this will cost me less than a euro / day over its warranty life of 3 years Nov 25 07:46:07 someone should stuff some modern motherboard(s) into a kaypro/compaq luggable case: https://upload.wikimedia.org/wikipedia/commons/thumb/7/7a/Kaypro_wikipedia.jpg/440px-Kaypro_wikipedia.jpg Nov 25 08:00:49 jow you pinged be earlier? Nov 25 09:02:56 aparcar[m]: yeah, it was about some weblate merge conflicts but I think I sorted it out now Nov 25 09:03:15 aparcar[m]: I didn't know that weblate has its own internal git repo which one can simply clone and fixup Nov 25 09:04:03 Yea I started to only use that instead of the PRs... Nov 25 09:04:53 jow: how would these lua parts be rewitten to something not lua? https://github.com/openwrt/luci/pull/3348/files#diff-e264f9a71e8c64ca3e349f065c0abde3 Nov 25 09:05:27 aparcar[m]: rpcd plugin Nov 25 09:07:10 You definitively would recommend to make it lua free from the beginning right? Nov 25 09:12:41 So i was having a hack on the apache package Nov 25 09:15:29 It is very broken in the current form as DSO (Dynamic Shared Object loading) is supposed to be disabled - at least the package does not ship any modules. However, DSO is enabled as all modules are marked to be built as shared modules. Forcibly disabling DSO (--disable-so) breaks the build. Nov 25 09:15:57 I guess that is why everybody has problems with the apache package right now. Nov 25 09:19:14 So... IMO basically all modules should be configurable via "make menuconfig" and DSO should be enabled as one statically built binary gives no _real_ performance benefit but removes the ability for the admin to add/remove plugins at will. Nov 25 09:20:25 Furthermore... PIC is used but --enable-pie is not. That's probably also not ideal Nov 25 09:53:59 aparcar[m]: nothing wrong with lua, you can happily write rpcd plugins in lua too... Nov 25 09:55:28 dkjson is "easy" but not very fast btw, there's luci-lib-jsonc if you're going to tie youself to luci anyway, and lua-cjson is packaged too... Nov 25 09:55:53 (luci-lib-jsonc could/should be a standalong package, not tied to luci, but that's work for someone to extract it) Nov 25 09:56:54 jow: morning, just try to wrap my head around this uci/default stuff, so i now need to align UCI defaults with the package/upstream defaults and cant set/change my own? So is this "? Is the "o.rmempty = false;" a accepted workaround to always get the value written? Nov 25 09:57:49 andy2244: yes, no Nov 25 09:58:00 watching out for default changes was always the case Nov 25 09:59:37 andy2244: you can also use the rmempty war if you insist, I can live with irt Nov 25 09:59:52 I just don't want to have this in base Nov 25 10:01:07 Ok so how do i handle this case: I want our UCI default to allow "Guest access", since we dont really handle user setup well in luci. Yet the samba default is to disable guest access. Now i should assume a average user understands that he/she needs to enable Guest access and make the share writeable by themself? Nov 25 10:02:39 its up to your uci -> nativ conf translation to handle this Nov 25 10:03:45 mhh thats to much hidden logic for my taste, if its fine for you i rather make those none default values via "o.rmempty = false;" and add a comment in the luci code? Nov 25 10:03:53 e.g. config_get_bool val $sectionid some_bool_val 1 Nov 25 10:04:30 I don't really understand the problem Nov 25 10:04:43 to me it sounds as if you introduce inconsistencies between ui and cli Nov 25 10:05:14 also the defualt state needs to be adjusted nonetheless otherwise luci will render the wrong checkbox state in case the underlying option is absent but defualting to true Nov 25 10:05:21 andy2244: if you want to have your own defaults, bake it in onto the config files on openwrt you manage? Nov 25 10:05:42 if that is what you are after really Nov 25 10:07:38 but maybe I misunderstood Nov 25 10:07:45 I want "good" defaults for our users thats all, as noted the default case for us is guest access without needing to setup a smbuser + passward via commandline. Yet thats not the samba default. Nov 25 10:08:00 forget about samba defualt, thats not what I mean Nov 25 10:08:29 what happens if "option read_only" is not present in /etc/config/samba and the service is started? Nov 25 10:09:43 the share is not writeable Nov 25 10:10:14 because read_only implicitly defualts to true? Nov 25 10:10:18 yes Nov 25 10:10:23 why? Nov 25 10:10:46 is it coded this way in the init script? Nov 25 10:11:56 or because its smbd default logic? Nov 25 10:11:59 all values are coded the same, in init there is no special logic weather a value is a default or not. I simply translate the UCI config values to the samba values and omit if a value is truly empty. Nov 25 10:12:25 so smbd defaults a share to readonly if no "read only = no" is given? Nov 25 10:12:39 yes Nov 25 10:12:52 that is ... highly unintuitive Nov 25 10:13:36 okay and instead of flipping that logic in the init script (to avoid special casing I presume) you want to paper this over in the gui with diverging defaults? Nov 25 10:13:41 the default value is "read only = yes", i simply wanted to change this for our defaults, same with guest access Nov 25 10:13:54 yes Nov 25 10:14:41 the thing is, I usally like to avoid ui patterns where saving the form once without actually doing any changes results in changes to the underlying config Nov 25 10:15:23 after the workaround you want to apply, saving the map without ticking any options would suddenly make readonly shared writable Nov 25 10:15:35 or is the default /etc/config/samba shipped with the flag option already set? Nov 25 10:16:02 i'm open to suggestions, but i'm not happy with a share thats neither reachable (no guest access) or writeable by default. From my expierince those are the two biggest problems i see in my support threads Nov 25 10:16:32 I totally understand the desire for these defaults Nov 25 10:17:04 I just wonder if the ui is the proper place to implement these, I'd imagine that cli users would expect the same behaviour Nov 25 10:17:43 but anyhow, feel free to apply that rmempty workaround, if it works for you then fine with me Nov 25 10:18:16 for cli to behave the same way, i need to change the luci + init script defaults Nov 25 10:18:45 I didn't know that you apply different ui defaults compared to the cli, hence my confusion Nov 25 10:19:05 np, i Nov 25 10:19:37 i was also confused about the luci defaults stuff, it kinda makes sense in a general sense, yet its easy to trip over this logic Nov 25 10:20:21 I don't understand, that couldn't you just introduce your own default samba config that does do what you need without changing any UX/init stuff? (me missing something is very possible) Nov 25 10:20:27 as noted if there are no defaults in upstream for a meta/unknown value, you need to take extra care since the default is not written Nov 25 10:20:56 I wanna understand, not so argue against (or towards) anything in particular =) Nov 25 10:21:28 olmari: andy2244 is the maintainer of the luci app Nov 25 10:21:43 its not about customizing the personal config Nov 25 10:21:44 ah... that makes helluva lot more sense xD Nov 25 10:21:59 yes thats what we discussed, yet there is no clear way to-do this atm, since either changed defaults need to-be matched in the init script and luci ui Nov 25 10:22:24 correct, luci, by defualt, assumes that initscript/cli defaults are aligned with form defaults Nov 25 10:22:25 All this makes way too better sense in this context :D Nov 25 10:22:25 ah lol ok, thats what you ment Nov 25 10:23:12 what about using a ListValue instead of a flag? Nov 25 10:23:24 ok thanks jow, i now understand the problem and have some ideas i can try. You are correct that cli should behave the same as luci, since especially cifsd was designed to work on low memory devices via cli... Nov 25 10:24:13 nvm, ListValue follow the same logic Nov 25 10:24:28 if form value == default value, remove option from config unless .rmempty = false Nov 25 10:25:37 i guess i will have to use the rmempty logic for luci and also change defaults for the init or add special logic for those cases, need to think about it Nov 25 10:25:42 and what you assumed/expected is a form preselect default value which does not affect the storage of the option Nov 25 10:26:27 unfortunately there is no such thing (the closest emulation would be a ListValue without any .default where the first choice is what you'd like to preselect) Nov 25 10:27:00 but not sure if that'd work or if it would add a "-- please select --" if rmempty is unset Nov 25 10:27:14 so yeah, go with rmempty = false Nov 25 10:27:45 ok thanks again for the help Nov 25 10:28:53 andy2244: dnsmasq has just had a similar change due to a new default behaviour in dnsmasq - this prompted an init script change AND a luci tweak :-) Nov 25 10:30:41 andy2244: btw thank you for your efforts on cifsd. Nov 25 10:31:03 yeah i guess, i also just noticed that i have the same problem with Directory mask/create mask which is 0744 vs 0777 what most users might want. Nov 25 10:31:47 i guess i always "hacked" it for my shares via my meta "force root" option... Nov 25 10:33:14 np was just feed-up with how complex and big samba4 was, so was looking for a alternative, so far the devs did a good job getting it to the current "useable" state Nov 25 10:35:58 andy2244: well I was fed up with how I couldn't get openwrt to build with samba4 package enabled under mac os. cifsd offered a way out of that....especially now that I've got the glib2 dependency building too. (I need gettext support... you've got it..look! Oh you mean you really want msgfmt command support...I'll add that to the PATH then). :-) Nov 25 10:36:16 btw if anyone wanna help test ad-dc and ldap domain stuff for samba4 again, i have a new package ready thats basically a fully build samba4 suite over at my repo: https://github.com/Andy2244/openwrt-extra/tree/master/samba4-suite-full Nov 25 10:36:44 * ldir runs away :-) Nov 25 10:38:35 * ldir does flash upgrade - back soon...hopefully Nov 25 10:40:33 * ldir is back - you'll have to stop talking about me now :-) Nov 25 10:41:35 +1 from me on letting ldir keep his voting rights Nov 25 10:41:43 ow. he's back :o Nov 25 10:41:54 * ldir lols Nov 25 10:42:15 xback: your timing hasn't improved has it :-) Nov 25 10:42:26 it even got worse Nov 25 10:42:43 but I'm also aging :-) Nov 25 10:43:16 your ageing won't improve with 4.19.86 Nov 25 10:43:30 pushed to staging Nov 25 10:43:51 ldir: or maybe exactly the _aging_ will improve ;D Nov 25 10:44:32 the gemini change made me go huh? for a while Nov 25 10:46:27 I wonder if there will ever be a commit upstream which states: "This finishes the development of the Linux kernel. We consider it as Done" ;-) Nov 25 10:46:47 would make my life easier each week .. ;-) Nov 25 10:47:02 Someone would screw up the backport! Nov 25 10:47:17 lol Nov 25 10:50:13 ldir: yeah i even can't ClearLinux as my dev distro, since i did run into small problems... now i just use debian 9 as my dev VM. For macos i only have my package builder to get specific packages build, not the whole image. The other docker env should work for macos. Nov 25 10:50:56 yay - I did the same changes as you (xback) on the refresh Nov 25 10:53:38 andy2244: yeah everything works under docker, but docker on macos is on the slow side of things...and fundamentally I like to build on the host OS...we (well I) find stuff/surprises and I think it helps avoid monocultures. Nov 25 10:54:41 ldir: thanks for checking. Nov 25 10:54:48 I also peeked at your changes afterwards Nov 25 10:55:22 yeah docker on win10 is also a mess atm... there are like 4 different ways to get linux containers running and none of them is production ready and stable... Nov 25 10:55:29 Inspired-by: Kevin Darbyshire-Bryant ;-) Nov 25 10:55:58 alright, I got apache with a good chunk of modules to work correctly Nov 25 10:57:21 if you're inspired by me you've got SERIOUS problems :-) Nov 25 10:58:29 I will try to propose a solution shortly Nov 25 10:58:51 jow: um just noticed cifsd actually don't document there defaults the help only list what options they support... i would have to check there sourcecode atm to get the real defaults :p so much fun Nov 25 12:17:30 ldir: speaking of monocultures, could you please try `make package/arm-trusted-firmware-mvebu/compile V=sc` on macOS and provide your feedback to https://github.com/openwrt/openwrt/pull/2521 ? Nov 25 12:42:14 btw if i change the luci/js module code, do i need to regen the whole translations again, even if no actual parameter was added but the code line numbers changed? I noticed that the translation stuff save the actual line numbers? Nov 25 12:43:34 I assume the line numbers are just some debug stuff and the lookup is a str compare? Nov 25 12:50:42 any lawyer around? :) What license is that one at the top of the file target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4018-jalapeno.dts? Nov 25 12:51:50 it looks like MIT, but if one actually compares it, then it doesn't match Nov 25 12:54:18 ynezz: I think it's ISC license Nov 25 12:55:08 re your other question - currently building the mvebu toolchain and we'll see what happens. Nov 25 12:56:44 ynezz: https://github.com/jedisct1/libsodium/blob/master/LICENSE Nov 25 12:57:04 yep found it already https://spdx.org/licenses/ISC.html Nov 25 12:57:06 thanks! Nov 25 13:21:33 ldir: ping Nov 25 13:21:58 ldir: regarding https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/backport-4.19/380-v5.3-net-sched-Introduce-act_ctinfo-action.patch;h=909c68e1b51621fbb3192b0bf10f3b45e5352e16;hb=3f5cf3872d078ca50849e08db3890718624bd0fb Nov 25 13:22:22 are customizations present compared to upstream v5.3+? Nov 25 13:23:46 nbd: regarding https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/backport-4.19/370-netfilter-nf_flow_table-fix-offloaded-connection-tim.patch;h=7c10f6f1897e1bab8fa3679ecfb9573084d2ad4a;hb=3f5cf3872d078ca50849e08db3890718624bd0fb Nov 25 13:24:13 nbd: should this be upstreamed? is this still required on 5.4? Nov 25 13:28:40 xback: err, let me check - I can't remember if it's a straight backport or if there are tweaks for 4.19 Nov 25 13:30:50 andy2244: the translation is not using these po files directly, they're compiled into binary files Nov 25 13:31:33 ah ok so i don't have to regen/upload everytime a do a trivial change. Nov 25 13:31:36 you can leave the .po files as-is unless you add new translation strings, they'll eventually get updated by a treewide translation sync again Nov 25 13:31:50 ok Nov 25 13:38:48 ldir: in the patch, selftest adds +CONFIG_NET_ACT_CONNDSCP=m, while upstream you add CONFIG_NET_ACT_CTINFO=m Nov 25 13:39:04 is CONNDSCP the old name or so? Nov 25 13:39:49 ah, that's a cockup - indeed conndscp was one of the original names until several rounds of shedding the bike came up with a new one. Nov 25 13:39:59 Looking at the patch contents Nov 25 13:40:18 I would guess that the current one in 4.19 is not the final which was accepted upstream? Nov 25 13:41:38 ctinfo is the correct name for the module, and should be what is self tested. Nov 25 13:42:02 ok. thanks Nov 25 13:43:08 it was 'fun' during the devel to submit to upstream and maintain 2 backports whilst there were active changes in the area as well Nov 25 13:43:41 no worries, just wanted to be sure :-) Really cool feature! Nov 25 13:49:21 sorry guys - openwrt on hold for a bit - other half wants to go shopping Nov 25 13:50:55 xback: thanks - it's a shame it's only 50/75% done (depends on perspective) the restore bit is there in the kernel, the store bit is done for iptables on openwrt but not upstream 'cos they want an nftables version and well..my head explodes looking at nftables. Nov 25 14:41:50 nbd: blogic: Would this patch still be relevant in 5.4? knowing that we are using GCC 8.x en have 9.x also present. https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/pending-4.19/220-optimize_inlining.patch;h=e6a9c19cac06910204d0a21e468af99243a0c84d;hb=3f5cf3872d078ca50849e08db3890718624bd0fb Nov 25 14:42:57 xback: already preparing 5.4? :) Nov 25 14:43:35 non-offically: yes Nov 25 14:43:59 whether it has value will be decided by the voting process :-) Nov 25 14:44:39 we're going to vote about such things as well now? Nov 25 14:45:00 I've probably missed previous votes Nov 25 14:45:24 well. there was a discussion ongoing if the next release (20.x) should be based on 4.19 or 5.4 Nov 25 14:46:14 If the majority feels 5.4 should be it, then I think it's good to be early. if not, then I think I'm actually adding support to soon Nov 25 14:47:28 but isnt that why we have kernel_testing_version in targets? Nov 25 14:48:03 yes. but the major effort goes into going through each separate patch. Nov 25 14:48:08 so, early support is good for people already working at migrating targets, too, but won't prevent us from having a 4.19 release Nov 25 14:48:28 exactly, 5.4 is fine, question is just when Nov 25 14:48:58 we don't know how stable and how many targets will be ready for first 20.y so I would assume, that it's going to be still on 4.19 Nov 25 14:49:27 2nd release in 2020 could be doable with 5.4 and no stress Nov 25 14:49:55 but it depends when the first 2020 release is branched :) Nov 25 14:51:55 maybe that the bump to 5.4 is painless and we can make it to the 1st 2020 as well Nov 25 14:52:45 yeah true :-) Nov 25 14:53:03 assume it's going to be 20.02, it's just 3 months away, with major holidays in between... Nov 25 14:53:20 I'm not expecting 5.4 any time for 20.02 Nov 25 14:53:56 I'd rather consider having an early 4.19 release Nov 25 14:54:03 but the discussion was around 2020 in general using 5.4 :-) Nov 25 14:54:18 and IIRC nobody has objected Nov 25 14:54:22 since openwrt-19.07 branch is already somewhat old Nov 25 14:54:59 anyone seen the article on Phoronix a week or 2 ago regarding speed in kernel versions? Nov 25 14:55:09 nope Nov 25 14:55:35 looks like 4.14 was the fastest atm. and suddenly some regressions kick-in having severe impact no speed Nov 25 14:56:06 not sure at the time of publish if it was related to some cpu mitigations Nov 25 14:57:32 so they're comparing apples and oranges? Nov 25 14:59:11 ahh, 5.4 already out Nov 25 14:59:41 time to bump desktop Nov 25 15:00:08 yay Nov 25 15:02:18 good morning Nov 25 16:22:08 iwinfo on 19.07 (from yesterday) isn't quite as informative as one would hope. https://bpaste.net/show/VFN3U Nov 25 16:22:17 also the assoclist is empty even though clients are connected Nov 25 16:22:41 the vaps use a variety of encryptions from none over psk2 to wpa3-mixed Nov 25 16:22:56 can anybody confirm such a misbehaviour? Nov 25 16:25:13 hexa-: mine looks better (openwrt-19.07-based downstream) Nov 25 16:25:15 https://zerobin.fff.community/?81d94cac32c23e10#Me/khG1WpMWbR5JgcaJjhvWqtARxs2LiJO8/UGpOUKU= Nov 25 16:25:28 wdr4900-v1 Nov 25 16:25:39 adrianschmutzler: might be related to wpa3-mixed and sae-mixed that I had before Nov 25 16:25:46 let me downgrade that Nov 25 16:26:26 I'm about one week short of current openwrt-19.07 head Nov 25 16:26:56 the last iwinfo changes happened in october, so that's probably fine Nov 25 16:27:41 hmm... did the tplink wdr4900 kernel partition size issue in bootloader ever got resolved BTW? Nov 25 16:28:10 olmari: afaik yes Nov 25 16:28:19 i think so Nov 25 16:28:30 it was broken for a while but I have recent 19.07 releases on mine as well Nov 25 16:29:09 hexa-: on wdr4300 (ar71xx) I have even more data in iwinfo Nov 25 16:29:24 this is an archer c7 v2 (ath79) Nov 25 16:30:39 don't have an ath79 available ATM to check. Nov 25 16:31:02 and this those devices are Freifunk, no wpa etc. in place Nov 25 16:31:09 yeah, same here Nov 25 16:31:53 jow: do you have an idea what could be the issue here? Nov 25 16:32:02 afternooning :) Nov 25 16:32:07 hexa-: Archer C7 v5 here, with 19.07-rc1, and iwinfo seems to work fine Nov 25 16:32:19 Cool, then I'll upgrade clients wdr4900 with next stable when it comes :) Nov 25 16:32:20 zorun: ath79? Nov 25 16:32:22 yes Nov 25 16:32:41 hmm, reboot *shrug* Nov 25 16:32:54 I only use mixed-psk Nov 25 16:33:06 with 2 SSIDs per radio Nov 25 16:40:36 well, I think it's due to not detecting the hardware and relying on the wext interface? Nov 25 16:44:20 zorun: ath10k or ath10k-ct? Nov 25 16:46:45 https://bpaste.net/show/DYMDG Nov 25 16:47:02 it doesn't find vendor/model ids for the vaps … rip. Nov 25 16:47:30 hexa-: you have c7 v2? because ath10k got just removed for v1 Nov 25 16:48:21 hexa-: it's just the standard 19.07.0-rc1 build, I think it's ath10k-ct Nov 25 16:48:42 adrianschmutzler: yes, v2 Nov 25 16:48:48 zorun: yeah, it defaults to -ct Nov 25 16:48:56 yup: kmod-ath10k-ct - 4.14.151+2019-09-09-5e8cd86f-1 Nov 25 16:49:01 ath10k-firmware-qca988x-ct - 2019-10-03-d622d160-1 Nov 25 16:49:12 ath10k-firmware-qca988x - 2019-10-03-d622d160-1 Nov 25 16:49:14 kmod-ath10k - 4.14.155+4.19.85-1-1 Nov 25 17:27:33 xback: ping Nov 25 17:46:46 ok, so looks like the iwinfo probe for nl80211 fails for some reason Nov 25 17:54:22 anyone interested? https://forum.openwrt.org/t/support-for-adtran-bluesocket-bsap-2030/48538 Nov 25 17:54:33 i would give it a go myself but i dont know where to start Nov 25 17:55:32 i did get the QCA986x/988x detected but it cant read its cal data Nov 25 18:04:52 b Nov 25 18:24:10 xback: kernel slowdown mainly has to do with newer spectre exploits. older kernels should ge betting slowed down soon enough :P Nov 25 18:25:23 * mangix wonders if OpenWrt kernels should be ran with mitigations=off . probably not. Nov 25 18:33:35 in theory, we own the cpu and don't execute any foreign code. Nov 25 18:35:50 true. but then again LXC is a thing Nov 25 18:37:18 I'd say not to touch it too... while slowing down is sad, sad thing, this doesn't differ from for example running wifi off per default etc, except this is even nastier issue if attacker wants to... Nov 25 18:42:55 ..hard things are hard.. in theory etc.. in theory we'd want perfect system without flaws =) Nov 25 21:08:20 mangix: nut doesn't build again: https://gist.github.com/f82818fc15a64a636bf1f8a410524104 Nov 25 21:08:29 I thought you fixed that Nov 25 21:09:10 running into this while building an image to test domoticz with your PR Nov 25 21:16:22 ynezz: libubox doesn't build for me: https://pastebin.com/rZMac9c2 Nov 25 21:21:19 KanjiMonster: meh, what gcc version is that? Nov 25 21:21:49 ynezz: gcc version 4.8.4 Nov 25 21:22:27 KanjiMonster: probably caused by -WError -WExtra Nov 25 21:22:41 caused by old compiler Nov 25 21:22:42 :) Nov 25 21:23:40 4.8 is still supposed to be supported ;) Nov 25 21:24:17 ...changing that in... 3.....2...1... (just had to, sorry) Nov 25 21:24:47 it's queued https://patchwork.ozlabs.org/patch/1193826/ Nov 25 21:27:46 I'll look at this tomorrow unless anyone else beats me to it Nov 25 21:28:37 it builds on macos which is great ;-) Nov 25 21:28:45 in order to prevent this, we should add all the supported compilers to the CI build mix Nov 25 21:29:31 so it probably means another three compilers 4.8, 4.9, 5 Nov 25 21:29:55 does it really make sense in 2020? Nov 25 21:31:16 I reverted the last ubox commit for now for me because all I want to test is rmk's sfp patches, so I don't care about it working more than 5 minutes ;) Nov 25 21:31:32 are you going to merge them? Nov 25 21:32:28 gonna borrow a few sfp modules from work tomorrow to test them a bit better, but I can take care of them - don't have more than a clearfog pro though to test Nov 25 21:33:00 KanjiMonster: BTW what distro is that? CentOS 7? Nov 25 21:33:39 KanjiMonster: do you have the GPON sticks? Are they running OpenWrt? Nov 25 21:34:39 KanjiMonster: most of the backports should go to target/linux/generic/ Nov 25 21:35:11 Hauke: gpon sticks? you mean fiber sfp modules? Nov 25 21:36:12 ynezz: a server I really should upgrade (maybe christmas ...) Nov 25 21:36:24 ubuntu server 14.04 Nov 25 21:36:31 KanjiMonster: yes the GPON fiver SFP sticks Nov 25 21:36:38 *fiber Nov 25 21:36:59 the one russell added support for Nov 25 21:37:54 Hauke: so you mean the Methode DM7052 NBASE-T module? Nov 25 21:38:44 the Huawei and Nokia ones Nov 25 21:38:56 KanjiMonster: ok you only have the Methode DM7052 NBASE-T ? Nov 25 21:39:32 Hauke: what? no, I was trying to figure out what you exactly meant by gpon sticks Nov 25 21:40:50 rullsel added support for "Huawei and Nokia GPON modules" I would like to know what is running on them Nov 25 21:41:02 as thesy need long time to boot it is probably Linux Nov 25 21:41:05 *they Nov 25 21:41:35 or Android :p Nov 25 21:42:50 mangix: and can you please avoid commits where you make multiple unrelated changes like packages:3e44ecbafa3b5fd49224bd516ad1011ab632d04a ? Nov 25 21:43:37 stintel: cannot reproduce Nov 25 21:45:56 mangix: did you try with x86/64 target on an x86/64 host? Nov 25 21:46:07 mvebu Nov 25 21:46:28 shouldn't matter Nov 25 21:46:34 except it does Nov 25 21:50:49 mangix: I reverted all libgd changes up to and including c9796cddae4b73905ebe85bf1287322203605e35 , then added the missing libwebp dependency and I can build nut fine now Nov 25 21:51:27 try running ./staging_dir/host/bin/pkg-config ./staging_dir/target-x86/usr/lib/pkgconfig/gdlib.pc --libs Nov 25 21:51:45 difference now is checking for gd include flags... -I/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/include Nov 25 21:51:47 erm missing asterisk after x86 Nov 25 21:52:03 with pkgconfig it uses /usr/include so it takes host include which is wrong Nov 25 21:52:39 ./staging_dir/host/bin/pkg-config: line 3: pkg-config.real: command not found Nov 25 21:52:48 aaaaand there's your problem Nov 25 21:52:55 Failed to open './staging_dir/target-x86_64_musl/usr/lib/pkgconfig/gdlib.pc': No such file or directory Nov 25 21:52:56 No package './staging_dir/target-x86_64_musl/usr/lib/pkgconfig/gdlib.pc' found Nov 25 21:53:19 why are you missing tools/pkg-config ? Nov 25 21:53:32 mangix: I'm not. if you run that manually ./staging_dir/host/bin/ is not in path Nov 25 21:53:41 oooooooooo nvm Nov 25 21:53:50 I have a local commit that fixes that Nov 25 21:54:21 this output from pkg-config.real is because I reverted all those commits I guess Nov 25 21:54:49 anyway let me first get this thing built with all this stuff reverted so I can runtime-test domoticz Nov 25 21:54:50 nah it's unrelated Nov 25 21:54:55 ok Nov 25 21:56:33 I have a local commit that fixes the pkg-config thing: https://github.com/neheb/openwrt/commit/70f8c0bbb23bb0e28362943cdcedea9931cb365b Nov 25 21:56:58 I have an issue with pkgconf and meson though Nov 25 21:57:49 I found where the issue lies but my python is not good enough to fix. Nov 25 21:58:11 Hauke: so no, I don't have that, I doubt we have any at work. We have mostly standard sfp modules (coppper and fiber). we do have some special sfp+ modules, but these require different cages than those found on the clearfog pro Nov 25 22:00:06 I wonder how I keep running into issues that are apparently not noticed, every time I build a new image for my apu2 Nov 25 22:00:24 does our CI not build x86/64 target on x86/64 host? Nov 25 22:00:43 I think our CI builds ar71xx Nov 25 22:00:48 or used to Nov 25 22:01:34 * stintel tests this nut problem on x86/64 target by building on !x86 host Nov 25 22:03:33 stintel: host sometimes matters. I ran into an issue recently where a CMake host package was getting installed to staging_dir/hostpkg/lib64 instead of lib Nov 25 22:03:47 Not a problem with Ubuntu Nov 25 22:03:51 * Strykar writes to PC Engines to ship an APU2 to each openwrt developer Nov 25 22:04:24 mangix: that's why we should have automated testing for building target == host Nov 25 22:04:36 these things keep slipping through too much Nov 25 22:04:55 every time I want to build or test something I run into unrelated issues Nov 25 22:05:15 and due to that I am unable to finish any of my outstanding tasks Nov 25 22:06:52 great. keepalived. next breakage. grrr Nov 25 22:08:20 stintel: out of curiosity, do you have a staging_dir/hostpkg/lib64 directory? Nov 25 22:10:31 ls: cannot access 'staging_dir/hostpkg/lib64': No such file or directory Nov 25 22:13:05 building my apu .config on ppc64el host now Nov 25 22:14:07 KanjiMonster: ok Nov 25 22:15:00 maybe I should configure my build pipeline to autocreate issues on github Nov 25 22:39:35 Hauke: mtk_eth problem is long standing. It does not happen with the upstream driver. Nov 25 22:41:07 mangix: ok **** ENDING LOGGING AT Tue Nov 26 02:59:57 2019