**** BEGIN LOGGING AT Wed Jan 27 02:59:57 2021 Jan 27 04:00:10 error: /home/mangix/devstuff/openwrt/staging_dir/toolchain-powerpc_464fp_gcc-10.2.0_musl/lib/libc.so 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 Jan 27 04:00:14 what an error... Jan 27 05:47:37 hmm interesting. GCC10 is broken with powerpc. Jan 27 06:03:41 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 98.4% packages reproducible in our current test framework.) Jan 27 09:23:20 build #610 of sunxi/cortexa8 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa8/builds/610 Jan 27 09:40:25 build #605 of ipq40xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ipq40xx%2Fgeneric/builds/605 Jan 27 10:16:16 build #639 of octeon/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/639 Jan 27 11:40:54 is BKPepe sometimes here? Jan 27 11:47:28 i think he is here right now: Pepe Jan 27 11:47:56 Yeah, I am here. Jan 27 11:48:07 You like me so much do you? (just joking) :D Jan 27 11:49:02 Oh it's you. Good to finally know Jan 27 11:49:47 I remember there where some interesting Turris patches in your tree somewhere, can you link me to your implementation of sysupgrades? Jan 27 11:50:35 AFAIK We are not using sysupgrade anyhow. Jan 27 11:51:18 Anyway all the patches can be found here https://gitlab.nic.cz/turris/turris-build/-/tree/hbk/patches/openwrt ; HBK-HBL branches are based on top of OpenWrt 19.07 and HBD is OpenWrt master Jan 27 11:51:26 does anyone know if the cgroup2 memory controller is supposed to work on linux 5.4? i get "write error: not supported" when i echo "+memory" > /sys/fs/cgroup/cgroup/subtree_control? Jan 27 11:53:56 Pepe: that's what I was looking for, thanks Jan 27 12:05:59 Pepe: https://gitlab.nic.cz/turris/turris-build/-/blob/hbd/patches/openwrt/to-upstream/0012-scripts-Don-t-skip-kernel-and-libc-in-Packages-gener.patch#L23 this seems wrong Jan 27 12:07:19 I will check it as I was doing just rebase as it didnt apply and I am not author of that commit. Jan 27 12:10:53 https://archlinuxarm.org/forum/viewtopic.php?f=60&t=14494 Jan 27 12:11:46 probably unrelated Jan 27 12:12:11 because some people say it's only negative benefit fo rthem... Jan 27 12:12:23 sorry, lost in the scrollback. no longer relevant Jan 27 12:21:10 aparcar[m]: The thing about this patch is that in the repository's index there is a missing kernel and libc and if it is not there, we can not update libc either kernel. We thought that this is done on purpose in OpenWrt as some kind of protection so you can not break your system while using opkg update/opkg upgrade. Jan 27 12:21:12 You can compare these two Packages index: Jan 27 12:21:14 https://repo.turris.cz/hbd/omnia/packages/core/Packages Jan 27 12:21:16 https://downloads.openwrt.org/snapshots/targets/bcm27xx/bcm2710/packages/Packages Jan 27 12:21:18 HBD is right now a few days old, because I need to rebase a few patches as you introduced autorelease. Jan 27 12:24:10 That's not anything bad, but we like your patch and idea of doing autorelease. Thank you! :) Jan 27 14:48:07 i am looking for someone or some people that would like to help me do some "sandbox" pentesting. these persons would get root access to my router and the goal would be to kick me off the internet or to escape the sandbox. the onle rule is that you dont use resources (ie saturate network or memory or storage) to cause a denial of service and kick me off that way. the only way to possibly improve the Jan 27 14:48:13 implemetation is to have knowledgable people scrutinize it and not just me Jan 27 15:12:09 Well, this is… interesting. https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.10-LTS-Planning-2022 Jan 27 15:12:39 Only two years of Linux 5.10 support if no companies step up to offer help. Jan 27 15:13:06 Can't blame greghk, though… Jan 27 15:13:16 *gregkh Jan 27 15:17:15 oh well, two years is still LTS compared to a normal one, Jan 27 15:17:29 if you're using 5.10 in a commercial context and expect 6 year LTS, then you have an obligation to help. Jan 27 15:20:44 auch, apparently since the last flash, ath10k-ct started crapping itself on my DAP-2695 Jan 27 15:21:24 greearb: does this look familiar to you: https://gist.github.com/cbc1cbb370dbe8857b867fdd4f8d566a ? Jan 27 15:25:52 karlp: I just take it as an incentive to run newer kernels. :) Jan 27 15:30:47 Yeah i kinda expect it'll be supported longer (hopefully), but ofc there's no point if it's not being used and updated to; That said I always find it weird when a new stable has an EOL date earlier than older stable kernels... that kinda is an incentive to stay with the older ones Jan 27 15:32:24 urjaman: If you prefer slower performance and/or lesser features… Jan 27 15:33:16 * rsalvaterra is still waiting for the MIPS32 eBPF JIT… Jan 27 15:33:44 With hardware that's running LTS kernels, usually updates only result in a bigger kernel, and hopefully the same performance :P Jan 27 15:34:58 urjaman: That depends a lot on the hardware, especially the architecture… Jan 27 15:35:32 rsalvaterra: so... what od you do with bpf? Jan 27 15:35:33 x86(-64), for example, typically receives much more love. Jan 27 15:36:11 karlp: Nothing. Yet. That's why I'm not holding my breath. :) Jan 27 15:36:36 yeah but basically unless there's somebody working to improve said specific hardware support, and you're not using any new software features, new kernels are mostly just bigger, and hopefully nothing broke Jan 27 15:40:06 stintel, I'll check that crash later. Jan 27 15:40:10 urjaman: Not really. It's easy to dismiss the kernel size increases as bloat if you don't follow the development. I invite you to peruse (at least) the linux-{kernel, mm, netdev, wireless} mailing list archives on a daily basis. You'll be surprised. ;) Jan 27 15:40:46 As I said, _if you're not using any of that_ Jan 27 15:40:58 rsalvaterra: still, for _lots_ of people, there's nothing in the new stuff. Jan 27 15:41:36 karlp: The core networking code is changed and fixed *all the time*. And it's vital for OpenWrt, for example. Jan 27 15:41:57 It's actually the most active subsystem in terms of kernel development. Jan 27 15:42:09 But anyways with most of the incentive for updating being security... having a newer kernel be supported for less time than the one you're on already... what. Jan 27 15:42:11 Yes, even more active than graphics. Jan 27 15:44:26 stintel: I was deleting /etc/config/network Jan 27 15:44:32 sysupgrade openwrt-ramips-mt7621-mikrotik_routerboard-750gr3-squashfs-sysupgrade.bin Jan 27 15:44:35 Device mikrotik,rb750gr3 not supported by this image Jan 27 15:44:37 Supported devices: mikrotik,routerboard-750gr3 mikrotik,rb750gr3 - Image version mismatch: image 1.1, device 1.0. Please wipe config during upgrade (force required) or reinstall. Reason: Config cannot be migrated from swconfig to DSA Jan 27 15:44:41 Image check failed. Jan 27 15:45:01 rsalvaterra: yeah, it changes _ALL THE TIME_ but not really a lot of it changes meaningfully for lots of users whose hardware already works. Jan 27 15:48:03 reiffert: Sounds like you're missing option compat_version '1.1' in /etc/config/system. Jan 27 15:48:24 (In the system section.) Jan 27 15:50:07 karlp: That's subjective, of course. It depends on the hardware one has. Jan 27 15:52:12 rsalvaterra: I was adding it, uci commit, and it's there but the message keeps showing when sysupgrade Jan 27 15:52:26 uci show | grep compat Jan 27 15:52:26 system.@system[0].compat_version='1.1' Jan 27 15:53:11 sorry if this has been discovered and/or discussed already, but the bump of 19.07 to 4.14.217 breaks building the wireguard package Jan 27 15:53:24 looks like upstream wireguard-linux-compat has the fix already Jan 27 15:53:26 https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/wireguard-linux-compat.git/commit/?id=1bb90881971c226d45c0abd1ac16ce3d6b77fc5f Jan 27 15:55:13 reiffert: sysupgrade -f Jan 27 15:59:17 ok that worked. need to find a way to create the vlans through uci... Jan 27 16:02:22 it's not ideal but at least this way you keep the rest of the config without having to restore a backup, and then probably if you would restore a backup with old network config you would loose access to the device anyway Jan 27 16:02:42 br377: https://github.com/openwrt/openwrt/commit/2ecb22dc51a501ae619d183283bc7766f5c4fe76#commitcomment-46411959 Jan 27 16:02:46 lose* Jan 27 16:04:05 thanks @Pepe glad to see its on the radar Jan 27 16:04:15 I was building the trunk image with the image builder.. I was hoping I could easily install luci after that Jan 27 16:07:26 opkg update is working just no luci package inside the Packages.gz Jan 27 16:08:47 can someone shed some light how to get luci onto the trunk image please Jan 27 16:09:05 reiffert: src/gz openwrt_luci https://downloads.openwrt.org/snapshots/packages/x86_64/luci Jan 27 16:09:24 reiffert: put that in /etc/opkg/distfeeds.conf Jan 27 16:09:37 reiffert: replace x86_64 with your arch Jan 27 16:11:27 Thank you. While installing luci .. is there an effort to write a parser and converter from the old network file to the new network file? Jan 27 16:14:25 reiffert: there has been some talk about this, but I don't know if anyone is actually working on it. I'd browse to the mailinglist archives Jan 27 16:14:27 the old network->switch menu is gone in trunk .. what to do here? Jan 27 16:14:50 reiffert: it might actually be easier to modify /etc/config/network by hand Jan 27 16:15:47 I just lost it after unchecking [X] bridge interface ... Jan 27 16:16:18 it's back after rehoming my cable Jan 27 16:17:07 need to understand how to create/config the vlans .. Jan 27 16:18:09 just get the vlan section from your old /etc/config/network and paste it in your new /etc/config/network Jan 27 16:18:35 unlike that stuff changed Jan 27 16:18:41 unlikely Jan 27 16:19:41 hm. no swconfig utility. Jan 27 16:20:05 that's expected. DSA != swconfig Jan 27 16:23:46 aparcar[m]: https://gist.github.com/8ad2b73e4bffa5c9fad657a86bcd51cc Jan 27 16:24:15 i refuse to believe no-one genuinely cares for our selinux work and the well-being of it so i am going to lower the barrier for you all to try out our sandbox heres the url you can use a proxy so that i wont know who connected: http://defensec:skit123@openwrt.defensec.nl:7681 Jan 27 16:25:50 grift: the problem is that you call everything corner cases and the core policy will break stuff for many people Jan 27 16:26:52 selinux stuff doesn't build under macos so I'm not playing I'm afraid. Jan 27 16:28:13 you dont need selinux, you just need a browser Jan 27 16:28:31 branch 19.07 broke wireguard due to kernel update. here's the fix if anyone is allowed to upstream: https://gist.githubusercontent.com/aep/34ca9bc5a47211cc600db6faa995b775/raw/15a5f506e1e8581105c2e4548afca66d4ce6aefa/diff.diff Jan 27 16:28:52 aep: already on our radar Jan 27 16:29:21 stintel you just misunderstood that Jan 27 16:29:42 grift: I think you did but let's agree to disagree Jan 27 16:29:42 stintel: thanks so far. I'm currently not figuring out how that DSA thing works. I was installing ip-bridge and I guess I can make it work with the bridge command. But I wonder what path I should follow, make it work through the uci utility or throw everything in a hotplug file Jan 27 16:30:30 stintel: sure, its a matter of interpretation Jan 27 16:32:44 reiffert: I have to figure out that part of DSA myself, my DIR-860L doesn't use VLANs, so I haven't been forced to do that yet. maybe there is some more info in the forums? Jan 27 16:44:25 bridge vlan add vid 5 dev lan4 Jan 27 16:44:26 RTNETLINK answers: Not supported Jan 27 16:44:30 that's not it Jan 27 17:00:11 that looks good. https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html Jan 27 17:11:44 I dont know how but the configured vlans have survived a reboot Jan 27 18:23:41 I was re-adding the routes into /etc/config/network Jan 27 18:23:55 how can I make them apply and have uci configure them? uci commit was not doing it Jan 27 18:25:22 reboot worked. Jan 27 18:40:38 stintel: it's working. vlan id 1 is now untagged on the master interface. Previsouly it had to be tagged on the slave which was kinda odd. Jan 27 18:55:37 stintel, those wave-1 crashes are some sort of mem corruption in the firmware descriptors, you have hit same problem before. In case the new firmware is obviously worse than a previous one, then maybe something we can look out, but may also just random reproduction of previous issue Jan 27 19:09:43 reiffert: uci commit, then reload_config.... Jan 27 19:26:48 greearb: for me https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=e1938d3397ba2bc40d27dc4f97f8532228de6112 greatly reduced the crash frequency. it went from crashing once every 24-48h to crashing once after 14 days of uptime (that was 10 days ago, still running since then). this is on a Home Hub 5A with QCA9880-BR4A Jan 27 19:31:56 xdarklight, glad to hear newer FW is acting nice for you. Jan 27 19:44:42 not sure who that was but "gg" Jan 27 19:44:46 its back up Jan 27 19:44:56 you managed to kill yourself Jan 27 19:48:11 greearb: I don't recall having it this frequently Jan 27 21:26:16 stintel: dang it why is the version missing :/ Jan 27 21:32:19 stintel: is that from a buildbot or your local build? Jan 27 21:33:57 aparcar[m]: is this px5g-wolfssl? Jan 27 21:34:41 yes Jan 27 21:35:07 yeah just saw in my local buildroot something about 'fix your package' Jan 27 21:35:43 https://paste.debian.net/1183025/ Jan 27 21:38:49 make package/px5g-wolfssl/{clean,compile} V=s Jan 27 21:38:52 does that work? Jan 27 21:42:23 doing a compile run atm, will get back to you **** BEGIN LOGGING AT Wed Jan 27 21:48:20 2021 Jan 27 23:24:52 quassel failed Jan 27 23:24:54 lovely Jan 27 23:53:58 mangix: whats up? Jan 28 00:03:02 Who has played with Github actions? Anyone? Jan 28 00:03:30 Grommish: ya Jan 28 00:04:42 aparcar[m]: Is it persistent state or is it a fresh VM everytime? Jan 28 00:07:00 fresh Jan 28 00:07:17 Hmm.. It shows 62GB in use on the disk before I even start Jan 28 00:08:12 and I"m hitting: System.IO.IOException: No space left on device at Jan 28 00:08:20 when building.. thanks! I'll dig more Jan 28 00:12:27 you can clear the caches, not sure if you have any enalbed Jan 28 00:27:44 aparcar[m]: Don't think so, but I'll put in a removal for stuff to see Jan 28 00:29:55 https://www.armis.com/resources/iot-security-blog/nat-slipstreaming-v2-0-new-attack-variant-can-expose-all-internal-network-devices-to-the-internet/ Jan 28 00:37:12 Grommish: ? Jan 28 01:22:54 stintel: https://github.com/openwrt/luci/pull/4307 adds a nice introduction into dsa, the aspects I've played with so far on a gs1900-8/ realtek rtl8382m so far worked pretty nicely (but I sure haven't tested the really complex issues yet) **** BEGIN LOGGING AT Thu Jan 28 02:20:38 2021 **** ENDING LOGGING AT Thu Jan 28 03:00:03 2021