**** BEGIN LOGGING AT Sun Mar 28 02:59:56 2021 Mar 28 04:40:16 aparcar[m]: is the CI using a debian 10 image? Mar 28 05:07:04 mangix: i think so Mar 28 05:24:44 uh oh Mar 28 05:24:56 tools/squashfs4 is not compiling on big endian host Mar 28 05:25:53 aparcar[m]: what happened to this? https://github.com/openwrt/openwrt/pull/2916 Mar 28 05:26:33 mangix: do you still want this? Mar 28 05:28:18 that would be great Mar 28 05:43:34 hmm POWER8 is quite slow... Mar 28 06:00:49 Does anyone know if Host/Uninstall actually works? I can't call it on the make, but then again I can't call Host/Install either, so,.. Mar 28 06:02:04 I just end up getting: *** No rule to make target 'package/feeds/packages/rust/host/uninstall'. Mar 28 06:05:36 Oh, it seems it's called during (yet before) Host/Clean Mar 28 06:08:02 ldir: that NLS problem with iproute2 is like pulling loose yarn on a sweater. Upstream change exposed strange problem where LDFLAGS aren't being passed to $CC, causing test compile to fail. Why do I keep pulling?! Mar 28 06:34:36 zorun: any way to request installed packages on cfarm? Mar 28 07:05:50 Do any targets use ARMel Arch? I've not been able to find any, but.. Mar 28 07:08:27 Grommish: all of them? Mar 28 07:08:45 mangix: Educate me? Mar 28 07:09:06 all supported ARM targets are little endian Mar 28 07:09:19 Ah ha Mar 28 07:09:21 there was a big endian one, but that got removed Mar 28 07:12:03 mangix: Thanks :) Mar 28 07:15:45 mangix: I'm trying to figure out which archs need libatomic and which don't and how to dep it Mar 28 07:20:20 Grommish: good luck figuring that out Mar 28 07:20:32 I recommend adding it as an unconditional dependency Mar 28 07:20:41 to avoid that headache Mar 28 07:20:44 Well.. It's mipsel and arm Mar 28 07:21:03 Yeah, That's how I have it now. I suppose it won't hurt the mips64 platform, but I have to test that still Mar 28 07:21:42 speaking of mips64, I'm connected to one running debian 10 Mar 28 07:21:45 it's so slow Mar 28 07:23:42 oh man I should be running time on this for the lulz Mar 28 07:25:13 mangix: I think this should be ok for the time being: ifeq ($(ARCH),$(filter $(ARCH),mipsel arm)) Mar 28 07:48:18 Grommish: just very roughly speaking, what would you think the chances could be for a cn5010 octeon plus with 700 MHz, 512 MB RAM and BCM53118? Mar 28 07:49:14 slh64: Well, the Broadcom chipset will make it difficult regardless.. The CN5xxx is supported by the kernel, so I don't see why it couldn't work Mar 28 07:49:28 could that be worth looking at, or should I run away screaming ;) Mar 28 07:50:08 Netgear srx5308 is the device I might get my hands on Mar 28 07:52:34 slh64: Honestly, couldn't tell ya. I've only got exp with the Octeon3 and while it was easy, eh.. I'd ask damex, he has a vast knowledge of the Octeon line Mar 28 07:53:28 thanks, at least not a no-go yet Mar 28 07:55:39 I might have to escort it to the trash, so might take on a vacation before - no good memories about the (4 years abandoned) OEM firmware though Mar 28 08:00:20 octeon plus with bcm531xx ? Mar 28 08:00:29 what device is that? Mar 28 08:01:42 damex: https://wikidevi.wi-cat.ru/Netgear_SRX5308 Mar 28 08:04:44 device should be able to run with current generic octeon build but switch needs extra attention Mar 28 08:05:34 thanks Mar 28 08:06:23 mangix: This is how I ended up dealing with it.. https://gist.github.com/Grommish/f9fd48b30020bb2930a6af59c72b447a#file-gistfile1-txt-L19-L25 Mar 28 08:09:22 i don't care much for octeon target since 'people' started rushing changes there so feel free to add necessary support for main board and then consult with forums/github issue/anything else about bringing up that switch (broadcom is not know to work). you need to check what place does it take and how connectivity is working. cn5010 can have 3 mac interfaces Mar 28 08:10:06 you might have some ports directly connected to soc (with external phy) and other would use that switch Mar 28 08:17:20 thanks, I'm nit quite sure if I'll take the challenge - or if the device finds other uses beford I get to it Mar 28 08:28:29 slh64: That switch has a DSA driver for it.. https://www.kernel.org/doc/Documentation/devicetree/bindings/net/dsa/b53.txt Mar 28 08:29:49 thanks, that might be 'fun' to integrate into a non DSA target Mar 28 08:33:02 I need to find a rtl8367rb dsa file, but haven't had luck yet Mar 28 09:33:33 mangix: see the website Mar 28 09:34:48 aparcar[m]: I'm looking at revising a Makefile for LibHTP. Someone had one for an older version, It passes -fno-stack-protector, but then the way the Make was invoked was odd. I compiled/ran without an issue without passing -fno-stack-protector. Opinion on keeping it in? Mar 28 09:53:43 mangix: that mips host has known I/O issues, that's why it's so slow Mar 28 10:30:25 Grommish, the older version with "-fno-stack-protector" was probably because compiler/toolchain issues or upstream source issues - now its supposed to work since many distros use it Mar 28 10:30:40 issues with older compilers Mar 28 10:30:56 plntyk: So I can remove it? I couldn't find a reason to keep it, which is why I was asking :) Mar 28 10:33:25 i would remove it - libhtp source history does not indicate that there is major incompatibility with that compile flag Mar 28 10:33:45 plntyk: Appreciated! Mar 28 10:55:08 zorun: OK Mar 28 14:47:17 never used failsafe reboot in luci before, I noticed I can run it without login, is this by design? Mar 28 14:55:16 Yes Mar 28 14:55:52 Hm, or do you mean you can press something in luci to reboot to failsafe without logging in first? Mar 28 14:56:12 rr123: please clarify what exactly you're talking about. Mar 28 15:03:19 I compiled in luci-failsafe, visit https://192.168.1.1, I saw "Flash Firmware" and "Reboot" on the left column before I login luci Mar 28 15:05:33 https://imgur.com/a/FoLCUoR Mar 28 15:12:17 rr123: is that with root password set? Mar 28 15:12:38 it's the default, initial login page, yes normally for root Mar 28 15:13:01 tried in a incognito window, both http and https, and it persists Mar 28 15:13:39 rr123: ok, I have no clue, please wait for somebody who understands what that module should do and why. Mar 28 15:15:22 https://imgur.com/a/cXO1kFJ after login it is still there Mar 28 15:15:43 20.02 git checkout Mar 28 16:33:09 Thermi: adding CI is quite easy https://gitlab.com/ynezz/openwrt-procd/-/pipelines/277814183/builds Mar 28 16:34:46 Thermi: we've gitlab.com/openwrt for evaluation where some projects already has CI implemented so the CI checks are run after push and on daily basis like for example https://gitlab.com/openwrt/project/libubox/-/pipelines Mar 28 16:36:01 Thermi: some projects like for example libubox, ubus have even unit tests, libFuzzer based fuzzing, sanitizers, valgrind and more. Mar 28 16:38:05 Thermi: so you can already have actionable output from clang static analyzer for example https://ynezz.gitlab.io/-/openwrt-procd/-/jobs/1134592803/artifacts/build/scan/2021-03-28-153322-70-1/index.html so now "just" need to start fixing those Mar 28 18:43:36 rr123: luci-mod-failsafe is meant for initramfs recovery image builds Mar 28 18:43:49 it makes no sense to include it in normal builds Mar 28 18:43:59 and iirc it was even dropped in master Mar 28 18:47:18 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Mar 28 20:35:00 xdarklight: I think you have to configure the link status, speed, duplex mode, tx flow controll and rx flow controll manually when you do not use the phy polling Mar 28 20:35:05 this is in the same register Mar 28 20:35:41 The documentation for the GSW140 is very similar to the VRX200 documentation in this area Mar 28 20:36:03 Hauke: ah, so instead of using any of the _AUTO values we need the "fixed" values instead Mar 28 20:36:18 yes Mar 28 20:38:06 xdarklight: the gswip_phylink_mac_link_up() function is called with all these avlues Mar 28 20:39:23 Hauke: yes, at least in Linux 5.7 and newer. for older kernels only gswip_phylink_mac_config has the values Mar 28 20:42:34 ok, I didn't check older kernels Mar 28 20:43:31 * ldir ughs Mar 28 22:03:08 ynezz: ping Mar 28 22:23:41 my ninja treewide commit broke nothing. cool. Mar 28 23:06:07 mangix: are you thinking about to backporting it to 21.02? Mar 28 23:07:03 why would they? it's hardly a bugfix or security issue.... Mar 28 23:07:19 I mean, "let's change how things are built, on the stable branch..." ? Mar 28 23:12:46 Well, OpenWrt 21.02 was not released into RC yet. It should provide faster compilation of packages feed, it makes things easier to backport. And who knows when another version of OpenWrt will be released, so waiting for it 1-2 year does not have much sense in my point of view. Mar 28 23:15:52 the fact that people keep treating stablisation release branches as "just throw more in" is _why_ releases are always late... Mar 28 23:15:54 IMO Mar 28 23:17:58 In case of 21.02, there is a difference, because it was waiting for LuCI support for DSA, etc. But all the stuff is documented on OpenWrt doc and sb said in #openwrt-adm that RC should be gone in week or two, but yeah, I understand your reasoning, however, faster compile time is something what we can all benefit from, though. Mar 28 23:27:19 cpu time is cheap Mar 28 23:27:22 developer time is not Mar 28 23:28:14 you'll need hundreds of hours in saved compilation time to make up just a couple of lost hours in developer time due to introduced regressions Mar 28 23:30:59 Yeah, let's not delay OpenWrt 20.x (yes, it's 21.x because it slipped) even more. Mar 28 23:34:17 * Borromini is pining for 21.02 Mar 28 23:34:34 about to test drive the LuCI DSA support Mar 28 23:34:42 also meson/ninja... pft Mar 28 23:34:56 you need friggin python3 for the former and a C++ compiler for the latter Mar 28 23:37:25 and 15 years down the road python 3 will be EOL, python 4 will be around, introducing incompatible syntax changes and suddnely your "makefiles" (meson build recipes) stop working Mar 28 23:37:51 the same shit happened with scons already, yet another "let's do a build system just because" thing Mar 28 23:45:06 jow: correction, C++98 compiler Mar 28 23:45:24 upstream refuses to convert to C++11 Mar 28 23:45:56 jow: C++, WTF?! Mar 28 23:46:15 Pepe: no plans to do so. One thing about that PR is that I split it up to make it easier to verify with CI Mar 28 23:46:19 to be fair, cmake requires C++ as well, but I am not fan of that either Mar 28 23:47:03 mangix: C++ 98… Got Stroustrup's third edition sitting in the shelf behind me. Never really loved it. :P Mar 28 23:47:04 Pepe: lots of problems were discovered that way. It seems that the treewide PR broke nothing Mar 28 23:47:12 mangix: okay, understood. Mar 28 23:47:43 rsalvaterra: C++98 is cavetime. It maps to C89. C++11 maps to C99 Mar 28 23:47:56 and all the cool kids are on c++20 already Mar 28 23:48:16 karlp: no way. C++20 is not complete implementation wise Mar 28 23:48:24 Heh… It's what we studied at the university, at the time. :P Mar 28 23:48:30 not even GCC10 Mar 28 23:48:48 the cool kids are working on a Go build system generating Rust code which transpiles to WASM running on node.js to invoke gcc on three C file and one include Mar 28 23:49:02 lol Mar 28 23:49:14 because its faster! Mar 28 23:49:34 for the 2% of projects having 100.000+ C++ source files to compile Mar 28 23:49:54 what is this go build system? Mar 28 23:49:59 a joke Mar 28 23:50:02 (I hope) Mar 28 23:50:08 i do too Mar 28 23:50:08 mangix: you thinkthat stops anyone? Mar 28 23:50:52 karlp: I mean...maybe they use parts. Not the significant stuff Mar 28 23:51:23 I tihnk for a build system it makes sense to be very conservative about prereqs Mar 28 23:51:39 I'm pretty sure constexpr std::string is implemented nowhere Mar 28 23:51:46 not every environment has modern C++ compilers available Mar 28 23:52:22 anyhow, time to hit the sack. bbl/gn8 Mar 28 23:52:26 jow: the irony in what you said is that master currently assumes a modern environment Mar 28 23:52:36 mangix: hrm, pretty sure enough of it is... I've seen people doing lots with the co-routine stuff Mar 28 23:52:52 coroutines are nice Mar 28 23:53:44 Anyway, ninja is extremely conservatice Mar 28 23:53:48 *conservative Mar 28 23:54:33 The fact that it's not as broken as make is a net positive. Mar 28 23:54:58 mangix: it wasn't me introducing all this newfangled whizbang Mar 28 23:55:53 sure. but as it stands, master cannot be built with Debian 9 Mar 28 23:56:08 which is still a supported distro Mar 28 23:56:14 when I stopped looking it was able to, since then it detoriated Mar 28 23:56:14 sorry, LTS Mar 28 23:57:08 so whoever merged stuff that cannot build on Debian 9, should probably fix it Mar 28 23:58:20 bbl for real now Mar 29 00:04:14 mangix: Is ninja a drop-in replacement of make? Mar 29 00:06:04 rsalvaterra: no Mar 29 00:07:12 Thought so… I had to deal with meson/ninja last year, when I sent a patch to Mesa… Haven't really enjoyed the experience. :P Mar 29 00:08:54 rsalvaterra: it's drop in if using cmake. but otherwise no. Mar 29 00:26:24 some folks even hate cmake and swear by autotools Mar 29 00:30:00 lipnitsk: https://www.youtube.com/watch?v=0DvANC-mCUk Mar 29 00:36:13 ROFL Mar 29 00:37:37 honestly autotools has been a huge pain. There are also already several hacks in OpenWrt to deal with how broken it is Mar 29 00:37:58 yeah, and how horribly slow reconf and configure are Mar 29 00:38:48 I've become a fan of meson given how simple it is. Mar 29 00:39:30 wouldn't it be nice to have gettext-full use cmake. I bet that with ninja it would build in no time Mar 29 00:40:22 well, ninja has been rejected in base. but yes, cmake would make it build faster. Mar 29 00:41:09 Original PR: https://github.com/openwrt/openwrt/pull/2874 Mar 29 00:43:59 dcc.o uses 64-bit long double, /home/mangix/devstuff/openwrt/staging_dir/toolchain-powerpc_464fp_gcc-10.2.0_musl/lib/libgcc_s.so.1 uses 128-bit long double <--- FFFFFFFFFFFFF Mar 29 00:44:26 need to somehow fix GCC Mar 29 01:09:27 mangix: Katyushas firing to the sound of an atrocious German song… WTF have I just watched…? o_O Mar 29 01:21:05 rsalvaterra: that was in response to people liking autotools Mar 29 02:00:21 Evening All Mar 29 02:03:39 kab-el: is the eMMC on the Omnia connected through the SoC's sdhci support? I ask since the SoC apparently supports higher speeds but not as configured currently. Mar 29 02:07:54 mangix: What does PKG_BUILD_PARALLEL do? Mar 29 02:10:22 Grommish: adds -j parameter to make. Only compatible with packages that use make. Mar 29 02:10:54 So basically no packages using meson or CMake in the packages feed. Mar 29 02:11:20 Right, interesting. I can put that in, but to the Turris question, I answered that as well Mar 29 02:11:45 The Makefile was outdated, so I had to change some things, but I left the Header block intact Mar 29 02:12:44 lol what was the answer? Mar 29 02:13:45 That is certainly was, but I left the header block intact. I wasn't going to start from scratch Mar 29 02:13:58 and I needed libhtp for Suricata6 Mar 29 02:14:18 faux paux? Mar 29 02:15:50 It was either externalize it, or git clone libhtp every time I ran Build/Prepare :D which is how I was originally doing it Mar 29 02:31:47 Grommish: It depends. You could write to the PR description that you used the Makefile from source, that you done these changes, etc would be one approach than saying "it was outdated", I did just three changes and I am the author (according to Git like it is done now). The other approach would be to put the original authors and use Co-authored-by and in your Signed-off-by add to the [] which changes Mar 29 02:31:50 you made. Mar 29 02:32:07 Just my point of view. Mar 29 02:32:25 Same applies for commit message. Mar 29 02:34:06 Pepe: I'd honestly rather not deal with it at all, but since it' not in the tree.. I'm not credit harvesting :) Feel free to comment on the PR on how you'd like to see it.. Or, submit it yourself? I don't care how it gets there Mar 29 02:34:45 Grommish: Why do you have such approach like I started smth and then give up? Mar 29 02:34:45 Pepe: But as you pointed out in the Suricata PR, I'd rather not git clone each time, but if it is an issue, I can go back to doing that Mar 29 02:35:10 Pepe: It's not give up :) It's just path of least hassle Mar 29 02:35:53 Pepe: If you have a better, proper way, I invite you to correct the PR via comments. If you want to submit it yourself, please do. I just need it in the repo, or a work around on how to get it Mar 29 02:37:06 Grommish: For me it seems like you do. I told you what should be done and if I should repeat myself in that PR, fine. It seems you need it in upstream, so feel free to continue what you are doing. If you want to go back to the ugly way like doing git clone each time, then go. Mar 29 02:37:39 Pepe: I do not, which is why https://github.com/openwrt/packages/pull/15287 is there :) Mar 29 02:38:22 Pepe: You recommended a different way, I used it. How it gets into the OpenWrt repo I honestly don't care about, as long as it's there Mar 29 02:38:39 I am not going to reinvent wheel as it will be good to have it in upstream, but there should be some dependencies tighten to it or in other words, packages which are using that. Mar 29 02:39:04 I see that this is not going anywhere, sorry. Mar 29 02:39:34 Pepe: I'm not being argumentative, at least ot intentionally, but I'm not understanding what you are trying to convey Mar 29 02:40:15 Pepe: Instruct me on a better way, and I'll certainly go that route. My goal is least resistance for this since, let's face it, no one is going to actually end up using the package Mar 29 02:45:28 Pepe: I only need LibHTP for Suricata, which also requires Rust, so the use-case for either is going to be damn near nothing. Usually, anything I need is already in the build tree, this was not. You questioned git cloning it, and were right. You pointed to the Makefie for 0.5.33, and you were right :) I removed the ICONV stuff because it wasn't playing nice, and Build/Compile because the -fno-stack-protector was questionable and the $(MAKE) call Mar 29 02:45:28 was just redoing Build/Compile/Default Mar 29 02:48:38 Pepe / mangix: If it's an issue for either of you, simply close it and I'll go back to doing it the way I was Mar 29 02:48:52 I'm not getting worked up about it though Mar 29 02:49:14 mangix: it is Mar 29 02:49:54 mangix: i am not sure about whether the MMC supports it, but I have never looked into this Mar 29 02:54:31 kab-el: I have a Helios4 board (very similar SoC to the Turris Omnia) and am looking into getting some of my SD cards working (it has SD instead of eMMC). Apparently after kernel 4.19 something happened and high speed support broke. I'm trying to figure out what happened. Mar 29 02:54:56 sorry, after kernel 4.14 Mar 29 02:57:10 Pepe: This is the Makefile you linked to me :) https://gitlab.nic.cz/turris/turris-os-packages/-/blob/master/libs/libhtp/Makefile Mar 29 02:57:22 Grommish: I know why LibHTP is needed, but I didn't said that I dont want to see that in upstream or did I? I responded to your faux paux message that it could be done better than finding in the comments, which changes you did and why. If you want to have it in OpenWrt, go ahead and finish that. I am not doing it, because as you said, it requires Rust and Rust is needed for Suricata. Both things you Mar 29 02:57:24 have running or I suppose so accordings to PR. I havent ever tried it. Because I would need to compile it, test it and to see if it works and then I could send libhtp there, but all of this, in the end cost developer time if you said that it saves hassle, which it does not, though. Mar 29 02:58:42 Grommish: Also, I have running libhtp on OpenWrt 19.07 and I dont have it running for OpenWrt 21.02 either OpenWrt master, and thats why I am not sending it to upstream as it would be completely untested, which I am not doing. **** ENDING LOGGING AT Mon Mar 29 02:59:56 2021