**** BEGIN LOGGING AT Thu May 13 02:59:56 2021 May 13 08:32:20 [14:38] i mean right now, you can use ifup/ifdown to recreate the state of dynamically created interfaces like vlans, bridges, etc. May 13 08:32:31 jow: do you have any idea for handling that? May 13 08:32:56 jow: full nbd's comment from yesterday irc log: https://pastebin.com/raw/eK3x4TZh May 13 10:13:45 lynxis: I wrote a simple patch for busybox but now the openwrt patch system fails me May 13 10:14:16 lynxis: this is the patch https://termbin.com/2p9m May 13 10:14:26 but it fails to apply when using the build system May 13 10:18:01 [14:34] how about having a 'config bridge' section imply the creation of an implicit proto=none interface with the same name May 13 10:18:21 nbd: so that would basically just result in having network.interface.foo, right? May 13 10:18:27 (ubus object) May 13 10:33:58 jow: i agree with nbd that if we create bridge device (which results in Linux bridge interface), there needs to be a way for brinding it up & down using ifup / ifdown (AKA netifd + ubus "up" / "down" methods) May 13 10:34:47 jow: so we either need network.interface.foo for layer 2 bridge interface OR something like network.device.foo May 13 10:40:16 now, if we add something like network.device.foo and then user adds interface too, then "ubus call network.device.foo up" and "ubus call network.interface.foo" will do basically the same thing I guess May 13 10:40:47 oh crap, that layer 2 & layer 3 handling in Linux, netifd, UCI, LuCI is a mess May 13 12:04:47 * ldir suggests porting systemd to openwrt to solve all of this interface mess - hides May 13 12:14:10 well, Linux doesn't clearly distinguish layer 2 and layer 3 in its interfaces, while we want to May 13 12:14:21 the question is, where to do that May 13 12:15:21 ifup & ifdown commands are expected to work with Linux interfaces just like ifconfig May 13 12:15:39 so I think ubus objects network.interface.* should match Linux interfaces May 13 12:16:05 so if we add a bridge layer 2 interface, we should have network.interface. for it May 13 12:16:22 (which matches nbd's idea he posted yesterday) May 13 12:17:21 ldir: ping - https://git.openwrt.org/?p=project/mdnsd.git;a=commitdiff;h=eadfa26a5cf31e27f551c37c1362983e9db37c4d;hp=d13290b427487bb05581e11875af3bfe74d6da2d why + 1 ? May 13 12:18:55 ldir: dropping that + 1 fixes http://lists.openwrt.org/pipermail/openwrt-devel/2020-August/031149.html May 13 12:20:09 stintel: 'cos the original code did it and I assumed a) it was right b) it was for the null string terminator byte. May 13 12:20:51 ldir: ah, well I'm not that good at C so I'm even less sure it's right or not :P May 13 12:22:25 I get nervous with strncpy -> memcpy replacements - memcpy really doesn't give a shit about null terminators. strncpy sometimes cares. May 13 12:23:18 well yeah, that patch was not accepted because it's not the correct solution May 13 12:23:35 but I'm thinking the +1 is wrong May 13 12:23:53 Warning: If there is no null byte among the first n bytes of src, the string placed in dest will not be null-terminated. May 13 12:24:19 so if there is a \n we'll add it, if not, not, so the + 1 is bogus? May 13 12:24:26 or am I completely talking bs now :D May 13 12:24:37 s/add/copy/ May 13 12:24:47 ping nbd blogic ^ May 13 12:24:56 as either of you originally wrote that code May 13 12:26:03 I'm switching to binutils 2.36.1 and gcc 10.3.0 on all my builds as I would like to make those the new defaults in master May 13 12:26:12 and I'm hitting that May 13 12:26:21 Build [#98](https://buildbot.openwrt.org/master/images/#builders/26/builds/98) of `apm821xx/sata` failed. May 13 12:26:50 you'll note the following line "strlen(blobmsg_get_string(_tb[SERVICE_INSTANCE])) + 1" has a + 1 and again I'm assuming the idea is to make sure calloc includes space for a string terminator. May 13 12:28:57 ok what about this then: https://gist.github.com/97418a06403aed3b9d8faa1ce69b1f82 May 13 12:29:31 although that makes even less sense to me May 13 12:29:53 and that doesn't provoke the warning?? May 13 12:29:59 no May 13 12:30:06 where is the string terminator going to come from if it's not in the source to begin with ? May 13 12:31:23 I'm just going to drop the + 1 for now and build like this May 13 12:31:25 The strlen() function returns the number of characters that precede the terminating NUL character May 13 12:31:38 ah May 13 12:32:03 so an 8 character string takes 9 bytes - 8 for the string, 1 for the terminator May 13 12:33:02 to copy an 8 char string you must have 9 characters worth of space for the destination. May 13 12:34:23 yeah I get that May 13 12:34:45 pffft May 13 12:35:01 https://man7.org/linux/man-pages/man3/strlen.3.html May 13 12:35:05 man-pages are great May 13 12:35:14 I have that open in my browser :) May 13 12:35:21 :D May 13 12:35:26 but that's not helping to fix the compile warning May 13 12:35:37 now I need to look at strncpy - I suspect my error is that the strncpy should be strlen and perhaps no strlen+1. - can't remember what strncpy does! May 13 12:36:08 memcpy or strlcpy, don't use strncpy May 13 12:36:39 can always use memcpy and manually null terminate arrays May 13 12:36:57 change to memcpy was rejected May 13 12:37:03 see http://lists.openwrt.org/pipermail/openwrt-devel/2020-August/031149.html May 13 12:37:26 I mean, even strcpy is fine if you KNOW the destination has enough space May 13 12:38:01 I think your https://gist.github.com/stintel/97418a06403aed3b9d8faa1ce69b1f82 is a very valid solution. May 13 12:38:07 but that gave the same problem :D May 13 12:38:07 https://git.openwrt.org/?p=project/mdnsd.git;a=commitdiff;h=eadfa26a5cf31e27f551c37c1362983e9db37c4d;hp=d13290b427487bb05581e11875af3bfe74d6da2d May 13 12:38:25 it used to be strcpy originally May 13 12:39:13 we need n+1 of space, but only n of the source string. calloc will give as a null terminator already because it inits the alloc memory to nulls for us. May 13 12:41:10 ldir: will you commit that fix :D May 13 12:41:52 oh hell yes - I don't mind my name being dragged through the mud, I'm an idiot :-) May 13 12:41:58 heh :D May 13 12:42:27 I think gcc can make just about anyone feel stupid May 13 12:43:25 I think the compiler is trying to cover the case of 'oh but what if the end character isn't a null' not realising that it must be 'cos strlen must have fallen over a null to give is a string length. May 13 12:44:03 ok next problem: busybox :P May 13 12:44:12 It wasn't me! May 13 12:45:04 oh, fPIC blabla May 13 12:45:27 because PKG_ASLR_PIE:=0 May 13 12:46:39 Redfoxmoon: I agree strncpy is a horror show May 13 12:46:48 Yep. May 13 12:47:24 I understand the original intent behind it, but the implementation is wack May 13 12:48:24 yeah, let's just count the characters and still not really care if we terminate the string correctly May 13 12:48:45 :-) May 13 12:48:58 at least strlcpy is safe, but it does come w/ the fact that it will truncate May 13 12:50:19 stintel: ldir are you working on gcc 10? May 13 12:50:38 you'd have thought that null termination would be implicit - it IS called 'string n copy' May 13 12:51:01 I think https://lists.openwrt.org/pipermail/openwrt-devel/2020-August/031149.html is a wrokaround for a gcc bug May 13 12:51:18 I use gcc 10 as the toolchain compiler May 13 12:52:12 brb - have to collect mrs ldir from the dentist May 13 12:52:27 Hauke: 13|13:26:02 < stintel> I'm switching to binutils 2.36.1 and gcc 10.3.0 on all my builds as I would like to make those the new defaults in master May 13 12:53:11 stintel: thanks May 13 12:53:39 Hauke: what do you think of https://gist.github.com/stintel/97418a06403aed3b9d8faa1ce69b1f82 May 13 12:56:43 stintel: does it compile? May 13 12:56:58 I think the original code is not wrong May 13 12:57:06 but gcc 10 does not like it May 13 12:57:59 Hauke: yes, it compiles May 13 12:58:20 I'm about to flash my first device with gcc10+binutils2.36 combo :) May 13 12:58:44 It loks ok, calloc_a() makes surethe last byte is NULL and then it should be fine May 13 12:59:12 ok, I'll try to come up with a commit message May 13 13:12:30 Hauke: ldir: is that good enough? https://gist.github.com/0310f5b4e5b95b622fad77bbf7200fb2 May 13 13:14:03 stintel: looks good May 13 13:14:12 Hauke: may I add an Acked-by ? May 13 13:15:12 stintel: ok May 13 13:15:20 Hauke: thanks! May 13 13:15:22 stintel: umbim is also not compling with gcc 10 May 13 13:16:28 I should probably do full build :) May 13 13:32:16 stintel: good enough - you can add my acked by May 13 13:32:34 ldir: thanks, I'll push in a few minutes May 13 13:32:45 * ldir mrs ldir still has relevant teeth :-) May 13 13:33:11 ugghhh fscking IO problem May 13 13:33:22 every time I build OpenWrt when the kernel extracts all IO hangs May 13 13:33:32 seriously fscking annoying May 13 13:34:13 and my box doesn't support NVMe May 13 13:34:25 and PCIe to NVMe cards are hard to find over here May 13 13:37:36 maybe I should consider replacing my 8+ y old Intel 520 SSDs May 13 13:37:59 although I'd expect the scheduler to avoid this annoyance May 13 14:40:17 ldir: 5.10 is at .36. Are you bumping it, or shall I do it this time? :) May 13 14:40:46 you can check if I've done it right May 13 14:42:32 Oh, you're already on it, nice! I'll give it a look/spin, for sure. May 13 14:42:54 stintel: is your fs mounted with discard? it's a frequent cause of hangs on some SSDs May 13 14:44:05 zorun: it's not, as it's a SATA 3.0 device, queued discard was only added in 3.1 May 13 14:44:31 oh wait a minute May 13 14:44:45 that extracts to /home, those aren't my Intel 520s at all May 13 14:44:47 *facepalm* May 13 14:45:41 my /home is on btrfs raid1 on samsung qvo, sata 3.2 so discard _shouldn't_ be a problem May 13 14:46:05 but I guess I'll try disabling it to make sure May 13 14:47:25 ldir: Even better, I'll do it locally too and compare my results to yours. May 13 14:47:58 discard often *is* a problem ;) I mean the mount option, as some SSDs really don't like the way the filesystem issues lots of discards when you delete files May 13 14:48:26 I've seen multi-minutes I/O hangs on a samsung EVO when running big rsyncs with lots of small files May 13 14:48:34 blergh May 13 14:48:39 running fstrim regularly is fine May 13 14:51:52 zorun: thanks for mentioning it. I didn't even consider it because I have it disabled on my rootfs and didn't think about the fact that /home is on different SSDs. it appears it might have been the culprit after all May 13 14:52:08 systemctl enable fstrim.timer # fixed May 13 14:53:51 hmmm... should i disable discard on btrfs as well then or can that handle it better? May 13 14:54:01 * Borromini has discard=async set May 13 14:58:30 Borromini: I'm on btrfs so I guess it doesn't ;) May 13 14:59:33 :D May 13 14:59:34 thanks May 13 15:12:12 ldir: do you have 5.10.36 bump pushed somewhere ? May 13 15:12:41 as I'm planning to build new images for all my devices, it's the perfect time to test that also May 13 15:14:28 s/planning to build/building/ May 13 16:00:45 stintel: I've pushed mine, actually. May 13 16:01:29 stintel: https://github.com/rsalvaterra/openwrt/tree/5.10-bump May 13 16:02:36 oh, nvm lol, I'm not using 5.10 yet on most of my devices May 13 16:02:49 lots of brainfarts today May 13 16:03:48 stintel: Even better, it's the perfect opportunity to test! B) May 13 16:04:23 maybe not while switching from gcc 8 to 10 ;) May 13 16:05:06 Hm. The mac80211 patches need refreshing, I see. May 13 16:11:01 stintel: gcc 10, binutils 2.36 and musl 1.2.2 here. The edge doesn't get much more bleeding than this… :P May 13 16:11:25 when gcc 11? May 13 16:13:15 Ansuel: I wouldn't dare to bump it myself… compilers are scary, compiler patches are scarier. May 13 16:14:05 just asking if someone have some testing patch, can't remember when gcc 11 was released May 13 16:16:00 anyway looking at the patch for 10.3, there are only 18 and are not too big max 4kb... so doesn't look that different than the upstream gcc May 13 16:31:15 rsalvaterra: ping May 13 16:31:34 aparcar[m]: pong, what's up? May 13 16:32:45 rsalvaterra: how to submit patches to busybox May 13 16:33:28 aparcar[m]: It's the same as the Linux kernel, but you need to be subscribed to the mailing list, iirc. May 13 16:33:39 ack ty May 13 16:33:45 np May 13 16:42:13 nbd: has anyone reported trouble with unifi 6 lite since https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=06f5e8009d4470d0dc6bba28a8f946ac4448cba2? May 13 16:42:36 I tested a build from the previous commit and its ok May 13 16:45:09 on wifi it seems like most packets are just dropped, an occasional ping or two will get through May 13 16:49:29 which wifi chip? May 13 16:51:30 2.4 or 5 ghz? May 13 16:51:43 5 ghz May 13 16:52:35 haven't received any reports May 13 16:52:53 can you git bisect the mt76 driver? May 13 16:53:44 I can try but I dont know how, do you have any pointers? May 13 16:55:23 netprince: https://openwrt.org/docs/guide-developer/packages#config_src_tree_override May 13 16:55:45 that way you can use git in the package build dir\ May 13 16:56:37 ok I'll take a look May 13 18:24:12 aparcar[m]: We finally got our reply, heh? :) https://github.com/BR903/ELFkickers/issues/15 May 13 19:07:07 wtf, grub host build fails: https://gist.github.com/stintel/7d74bdc838922270dc91e6955b632380 May 13 19:07:14 it built fine previously ... May 13 19:07:45 stintel: there is a bug report this with some links to packages from upstream and buildroot May 13 19:08:04 it was created some days ago May 13 19:09:17 Hauke: yes, I've added a patch to fix that Decompressor is too big May 13 19:09:48 stintel: is this something else May 13 19:10:10 oh May 13 19:10:27 actually no May 13 19:10:28 stintel: The decompressor to big thing is fixed already? It bit me a couple of days ago. May 13 19:10:30 https://bugs.openwrt.org/index.php?do=details&task_id=3790 May 13 19:10:48 rsalvaterra: it's not. I'm hitting it now, so I added the upstream patch for that May 13 19:10:52 stintel: Right. Exactly that one. May 13 19:11:00 and then it triggers the automake thing May 13 19:11:11 yes this ticket May 13 19:11:57 but this makes no sense May 13 19:12:19 how does https://git.savannah.gnu.org/cgit/grub.git/commit/?id=6643507ce30f775008e093580f0c9499dfb2c485 add a python dependency May 13 19:12:25 it changes a single line May 13 19:19:30 but yes, it's that patch that seems to trigger the automatek 1.15 is probably too old May 13 19:19:37 makes no sense at all May 13 19:19:46 fscking autohell voodoo May 13 19:20:18 Also can't fathom where the dependency comes from. Weird. May 13 19:20:39 well I'm going to add the patch + PKG_FIXUP:=autoreconf May 13 19:20:53 let's try and fix the voodoo with more magic ;) May 13 19:20:58 could be that we use pre generated files before and if we change then automake has to run again May 13 19:21:13 Hauke: good catch May 13 19:22:37 so PKG_FIXUP:=autoreconf fixes that automake crap May 13 19:22:41 but then I run into other errors May 13 19:23:37 https://gist.github.com/f33216a6505bf1debebcc3b4de8349bb May 13 19:41:53 stintel: try https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=0c24301c21ba9a3a70d008499b89adbb312f4149 May 13 19:44:08 https://bugs.openwrt.org/index.php?do=details&task_id=3790&order=dateopened&sort=desc - there's in which shows what a flustercluck this is cos of all the autohell & then python host deps . May 13 19:47:56 https://patchwork.ozlabs.org/project/buildroot/patch/20200528215015.5018-1-yann.morin.1998@free.fr/ explains the fuckery afoot May 13 19:48:39 well we depend on python on the host system anyway, I'm trying a different approach May 13 19:48:47 https://gist.github.com/stintel/f33216a6505bf1debebcc3b4de8349bb#file-logspackagebootgrub2host-compile-txt-L1190 May 13 19:48:58 there is a 0 missing in the substitution May 13 19:49:19 but now figuring out where that sed command comes from in the first place May 13 19:49:37 more autohell voodoo and black magic probably May 13 19:51:43 probably - you seem to understand more about autohell than I do (or ever wish to) :-D May 13 19:52:16 m4 May 13 19:52:25 heh I don't understand any of it May 13 19:52:40 I'm just following a trail :P May 13 19:53:48 There are times I wish I'd actually done computer science...or been a proper programmer :-) May 13 19:58:50 I started Harvard CS50x last year but I never managed to finish the week 0 task May 13 19:59:02 had to make something in Scratch May 13 19:59:17 "writing" a program by dragging and dropping stuff in a GUI May 13 19:59:28 absolutely fscking horrible May 13 19:59:30 nice for kids or people with 0 experience May 13 20:00:10 but when inserting some extra logic in the middle of an existing block becomes a problem, I tend to get very agitated May 13 20:13:03 stintel: I thought Scratch was for primary school? May 13 20:13:16 well it's what CS50x starts with May 13 20:13:59 if it's any consolation, I get paid to "program" in LabView May 13 20:14:31 quite literally spaghetti code... May 13 20:16:36 luckily it can interface with C-libraries, so I can shove logic into real code :P May 13 20:17:46 stinte: I beg to differ. I find Scratch really nice. :) May 13 20:17:50 *stintel May 13 20:18:08 I mean, it's the whole point. It's for people with zero experience. May 13 20:18:16 I know May 13 20:18:33 And a WAY better way of learning how to code than with (GAH!) BASII May 13 20:18:37 BASIC May 13 20:18:54 At least in Scratch you have structure. May 13 20:19:06 well it's just not for me May 13 20:19:55 And kids really need to see the "code" making things move around the screen. May 13 20:20:48 stintel: I know exactly what you mean - I tried the same thing and fell into the same trap/lack of interest - I had great difficulty relating it to 'proper' programming in a non-gui language. May 13 20:21:04 * rsalvaterra started with ZX BASIC and isn't proud. May 13 20:22:26 lol - started with zx80 zx basic, then 'progressed' to ZX81 basic. then into some sort of hybrid z80 machine code/assembly by looking up the instruction codes from the back of the zx81 manual and 'assembling' by hand. May 13 20:23:43 Hi, I'm completely new to openwrt. It seems I got lucky that some devices I bought some years ago had prebuilt openwrt support. May 13 20:23:44 Now I have recently bought something new (and cheap). Turns out TP-link put out new hardware versions for most of it's devices since by now. Often downsizing flash and RAM May 13 20:23:45 I did see that device profile was added at some point "tl-wr841n-v14" which is supposed to support that thing. Only it's doesn't "easily" build (haven't been able to replicate online claims to success). May 13 20:23:45 I was just wondering if so explicit on not supporting 32/4, why keep the profiles arround and actively maintain them? May 13 20:24:25 J-L: because people self-building still can use it nicely. It's just to stop caring about extra load and issues with the build bots. May 13 20:25:41 J-L: new default package set can't fit 4 MiB flash anyway, so autobuilding the images is no longer possible. But it would be uncool to just drop all of it. May 13 20:25:58 J-L: the build process should be easy, what didn't work for you? May 13 20:27:24 well, it's been 12 years or something that I've did opensouce cpp builds, so it certainly rusty, with sadly less time to spend on it than I'd like May 13 20:27:24 so I went for trying to build it using a prebuild docker container May 13 20:27:38 openwrtorg/imagebuilder:ramips-mt76x8-openwrt-21.02 May 13 20:27:59 but pretty much anything I try says it too big May 13 20:28:21 [mktplinkfw2] rootfs offset aligned to 0x1986128 May 13 20:28:22 [mktplinkfw2] *** error: images are too big May 13 20:29:18 which sort of confuses me as none of the builds claim to be bigger then 3 Megs May 13 20:29:30 even with the default packages May 13 20:31:01 That align number is also throwing me off here, it seems to point to an addres at 26 megs, but no idea where that would come from May 13 20:31:28 anyhow, don't want to spam here May 13 20:31:38 so not expecting troubleshooting help May 13 20:32:01 but, if these things are maintained, how do you know they actually work, without building them May 13 20:32:26 e.g. https://github.com/openwrt/openwrt/commit/1deaf695ec02d765c9ae28b1bac264798ca54a05 May 13 20:33:23 rsalvaterra: that's probably why I can still remember 0x01, 0x11, 0x21 as ld [bc/de/hl],nn respectivly - EDB0 is 'ldir', C3nnnn is jump, C9 is Ret, CD is Call May 13 20:33:41 J-L: yes, you should run "make menuconfig" and disable packages you do not need. May 13 20:34:09 J-L: also it's not imagebuilder I had in mind, it's the build system. Imagebuilder doesn't really build the software, it just assembles the image. May 13 20:34:23 J-L: should be adequate for the purpose, just do not include extra software. May 13 20:34:56 ok, on a next endavour I'll go for using the actual build system May 13 20:35:05 IB should work too. May 13 20:35:25 I guess you're trying to include luci, try without. May 13 20:35:47 rsalvaterra: I'm 50 years old in not many days time. How the hell??!!!!!! May 13 20:35:49 well even a completly stripped version didn't get accepted May 13 20:36:36 e.g make image PROFILE="tplink_tl-wr841n-v14" PACKAGES="-dnsmasq -dropbear -ip6tables -iptables -odhcp6c -odhcpd-ipv6only opkg -ppp -ppp-mod-pppoe libustream-wolfssl -wpad-basic-wolfssl wpad-basic" May 13 20:36:49 -> Filesystem size 2159.46 Kbytes (2.11 Mbytes) May 13 20:37:16 still it produces that error, so it really feels like something is not working as expected May 13 20:37:44 but yes, my end goal would be to have luci, May 13 20:38:53 anyhow, one day I'll look at building a custom docker container to run such a build in and try it there May 13 20:39:14 aparcar[m]: lgmt. is there already an upstream patch available? May 13 20:41:11 J-L: so something is broken. Full buildsystem should work. May 13 20:41:30 lynxis: no i need to figure out how to submit it :) May 13 20:46:14 thx, for the input, have a nice day! May 13 21:01:02 oh and thanks for the great firmware btw May 13 21:01:03 the TP-Link TL-WA801ND v5 vendor firmware is pretty crap at IPv6 (the other one too), which makes them quite unpleasant in combo with Android 11 May 13 21:01:03 but flashing them by documented instructions and all my troubles on that front have disappeared May 13 21:01:04 one wonders why they insist on putting their own junk on there May 13 21:33:39 Build [#90](https://buildbot.openwrt.org/master/images/#builders/64/builds/90) of `realtek/generic` completed successfully. May 13 21:38:04 J-L: vendor SDKs probably. May 13 22:40:52 lynxis: all right I sent a patch to upstream May 13 22:49:12 can anyone explain me what https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=tools/automake/patches/000-relocatable.patch;h=d05b25e61c2e240b5c858fde7f2f13ce622958fc;hb=HEAD#l23 does ? May 13 23:01:45 * stintel gives up and uses ldir's grub commit May 14 01:32:53 Build [#45](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/16/builds/45) of `realtek/generic` completed successfully. May 14 01:59:26 nbd: here is that mt76 driver bisect causing the unifi 6 lite to stop working properly: https://pastebin.com/pdm7CxWh **** ENDING LOGGING AT Fri May 14 02:59:56 2021