**** BEGIN LOGGING AT Fri Mar 27 02:59:57 2020 Mar 27 08:29:57 ynezz: You can add my tested-by on an apu2 if that helps Mar 27 08:32:00 cool, thanks! Mar 27 08:37:15 I just tried x86/64 combined image in QEMU and it bootloops :p Mar 27 08:38:03 but it's probably not related to that bump https://bugs.openwrt.org/index.php?do=details&task_id=2935 Mar 27 08:41:38 my APU2 is definitely not boot looping... as otherwise you wouldn't be able to see this :-) Mar 27 08:42:23 its probably related to those combined images Mar 27 08:47:46 openwrt-x86-64-generic-squashfs-combined.img.gz is what I'm running Mar 27 08:51:36 hm, interesting Mar 27 09:11:17 ynezz: did you pad the image? Mar 27 09:11:23 before trying it in qemu I mean Mar 27 09:11:34 jow: nope Mar 27 09:11:45 IIRC it used to work just fine before Mar 27 09:12:25 I usually do something like dd if=/dev/zero of=test.img bs=1M count=300; zcat openwrt...img.gz | dd of=test.img conv=notrunc; sudo qemu-system-x86_64 -nographic -net nic -net tap -hda test.img Mar 27 09:12:38 but yeah, its probably not related to apdding Mar 27 09:14:42 https://gitlab.com/ynezz/openwrt/-/jobs/486871087/artifacts/raw/bin/targets/x86/64/config.buildinfo Mar 27 09:15:04 same config as on the buildbots I would say Mar 27 09:20:37 [ 0.719792] SQUASHFS error: squashfs_read_data failed to read block 0x2cc556 Mar 27 09:20:40 hmpf Mar 27 09:25:17 your padding trick fixed it Mar 27 09:26:52 maybe the reworked image code regressed Mar 27 09:27:03 iirc we forcibly enabled padding a while back to make images work ootb Mar 27 09:27:08 yep Mar 27 09:27:38 relevant parts from log http://paste.ubuntu.com/p/FXgkjh3yM9/ Mar 27 09:27:55 but it used to boot even without that padding Mar 27 09:28:09 just the overlayfs was unusable, few kBs Mar 27 09:29:49 probably related https://patchwork.ozlabs.org/patch/1261193/ Mar 27 09:30:57 Noltari: hi Mar 27 09:32:29 Noltari: I live upstream first whenever possible, so that patch is https://github.com/raspberrypi/linux/commit/43da8e8622e6116c8eb03690928e48e45a2aa919 Mar 27 09:33:45 Noltari: actually I don't know how you sync the patches, so unsure about the correct numbering in https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commitdiff;h=8f9804b4684b56dbb1fe992573b37c9fcabaee7a Mar 27 09:34:32 actually, that staging tree is already old, let me sync Mar 27 09:34:48 the new filename is 950-0491-add-Sensirion-SPS30-to-i2c-sensor-overlay.patch Mar 27 09:41:45 ynezz: did you get SPS30s? Mar 27 09:41:57 yep Mar 27 09:42:06 realistic values? Mar 27 09:42:33 ah wait it's pm, I was confusing with ccs811 eCO2 which is just a load of crap Mar 27 09:42:48 https://maps.sensor.community/#11/49.8522/18.3007 Mar 27 09:43:13 I've scd30 for co2 as well, but it needs driver first, on todo Mar 27 09:43:31 ah right, you were in ostrava Mar 27 09:43:46 for 40y, yes :) Mar 27 10:28:56 wigyori: just noticed it, any idea why build of sunxi/cortexa53 takes almost double of time (55min) in comparison to a7 (32min) and a8 (25min) ? Mar 27 10:30:13 ynezz first I rebase the rpi commits on top of the corresponding linux release Mar 27 10:30:30 after that I export them to patches and I remove the wireless and config patches Mar 27 10:30:57 then I remove the applied and reverted patches Mar 27 10:31:05 and finally I refresh them and reorder them Mar 27 10:31:23 a lot of work :) Mar 27 10:31:35 that number of patches is insane Mar 27 10:31:41 yeah, I know xD Mar 27 10:32:17 I could probably remove more patches, but it would imply more work, so... Mar 27 10:33:20 so considering it's already upstream, is that ok with you now ? https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=f4d7c890e27465a3097be868318be14e430571e9 Mar 27 10:34:35 worst case you'll renumber it during next refresh :p Mar 27 10:34:44 sure, go ahead Mar 27 10:34:59 I didn't know it was upstreamed, sorry for that Mar 27 10:35:46 Noltari: no problem, BTW how should be /boot/distroconfig.txt handled during sysupgrade? Mar 27 10:36:23 Noltari: IIRC my local changes were gone during sysyupgrade (didn't looked futher into this yet) Mar 27 10:36:24 that should be always replaced with the new version Mar 27 10:37:23 ok, so where are my local changes supposed to be? Mar 27 10:37:57 config.txt Mar 27 10:37:58 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/bcm27xx/image/config.txt;h=f8ca1bf2d492781bb3cec9be13c6f637095c86c8;hb=refs/heads/master Mar 27 10:38:07 # Place your custom settings here. Mar 27 10:38:29 ah, so this is going to survive during the sysupgrade, right? Mar 27 10:38:50 it's supposed to, but I never sysupgrade my openwrt rpis xD Mar 27 10:40:03 and what about cameras in OpenWrt? Mar 27 10:40:47 I haven't got any of them Mar 27 10:41:25 ok Mar 27 10:42:33 anyway, thanks a lot for your work on rpi in owrt Mar 27 10:44:09 :) Mar 27 10:51:01 it is supposed to survive Mar 27 10:51:12 iirc I implemented something to put it back in /boot before the reboot Mar 27 10:51:33 otherwise this was restored after reboot and you had to reboot again to activate your changes in it Mar 27 10:52:35 I just sysupgraded one of my Pi4's and /boot/config.txt is restored as it should Mar 27 10:53:08 ah, I should do the same for /boot/cmdline.txt Mar 27 10:53:11 someone with lantiq vr9 SoC knowledge here? I have here an unsupported router and have gotten into UART mode, and I want to back up the flash Mar 27 10:57:18 the bootloader is brnboot Mar 27 13:14:03 blogic: hey, can you send that survey patch upstream please, otherwise it'll stuck in downstream for ever ;) Mar 27 13:21:36 rmilecki: I can't seem to get user with LE routerboards to test my routerboot splitter, but since I'm confident it will work there too (the code is simple enough and I've tested it locally on x86), I'll submit the patchset anyway I guess :) Mar 27 13:21:41 users* Mar 27 13:44:23 My openwrt site navigation skills are failing - there used to be a document that described the package make file menu syntax.... damned if I can find it Mar 27 13:44:28 f00b4r0: sure, great Mar 27 13:44:47 rmilecki: it's bound to elicit a few comments I'm afraid ;) Mar 27 13:44:53 https://openwrt.org/docs/guide-developer/packages Mar 27 13:44:57 ldir: ^^ ? Mar 27 13:47:36 Yes, maybe. Perhaps it's the MENU:=1 thing I'm mis-remembering Mar 27 13:59:53 openwrt master on omap/beaglebone black has some quirks ... e.g. sysupgrade -n leaves the old overlay fs partition intact, afaict. Mar 27 14:36:35 * ldir headdesks Mar 27 14:43:20 If I have a package FOO with 2 variants, FOO-BAZ & FOO-BAR that both PROVIDE the same package (FOO) for dependency reasons, is it legal to be able to select both in the menuconfig, and if not, how on earth do I prevent that? Mar 27 14:45:02 it is, and you can't. Mar 27 14:45:10 the build will normally fail when they both try and provide the same files though Mar 27 14:45:39 jow: I may have stumbled across a workaround for my recursive dependency FUBAR, but now I have other issues :-) Mar 27 14:46:05 karlp: that probably explains why the build is failing. Mar 27 14:47:55 it's normally a pretty obvious build failure, "cannot install file x from package , it is already provide by...." sort of thing? Mar 27 14:49:05 karlp: build is taking a long time Mar 27 14:50:35 * ldir stares intently at the macbook - it's taking a very long time... what are you doing? Mar 27 14:52:33 success! Mar 27 14:53:04 * ldir now tries building with the other variant Mar 27 15:10:05 and it fails - the simpler variant fails. Mar 27 15:10:56 and a make -j1 V=s is really, really, really slow. Which is just odd 'cos it's built everything from last time. Mar 27 15:12:00 * ldir tries to exercise patience Mar 27 15:16:32 hmpf, so 5.4.28 doesnt boot on imx6 Mar 27 15:34:52 rmilecki: yes Mar 27 15:35:03 rmilecki: wrote it onto my task list paper Mar 27 15:35:13 its on position 9 in the queue ;) Mar 27 15:37:12 ynezz: does a53 take twice as long because it's got to build a 32bit and a 64bit toolchain? Mar 27 15:37:39 blogic: sounds like sth possible! thanks ;) Mar 27 15:38:15 rmilecki: i'll do it this coming week Mar 27 15:39:46 karlp: ah, wasnt aware about that Mar 27 15:42:46 ynezz: just guessing, but I kno wthere's a lot of problems with needing the "other" part for building parts of the ATF and so on. Mar 27 15:44:44 * ldir cries Mar 27 15:46:36 what is wrong with https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=2c16981ad1a05b4c9384c64b7e2b76f7b2f072d3 Mar 27 15:46:37 karlp: yeah, reminds me https://github.com/openwrt/openwrt/pull/2521 Mar 27 15:46:52 karlp: so perhaps it would be better to download that toolchain for sunxi as well :p Mar 27 15:47:07 if it's good enough for mvebu Mar 27 15:48:00 whats the problem to just use binary, precompiled ATFs Mar 27 15:48:13 shouldn't be that hard to automate it with docker sdk/ib Mar 27 15:49:21 that 30min price tag for each build from scratch is insane Mar 27 15:49:38 anybody with a ramips-based routerboard to spare for some testing? Mar 27 15:50:28 ldir: whats wrong this time? recursive deps? Mar 27 15:50:41 ynezz: I'm all for having ATF binaries. Mar 27 15:50:50 like, I'm glad people care baout being able to build them Mar 27 15:51:02 but as a distro, man, please lets have them as blobs ready to use Mar 27 15:51:48 ldir: I think it is problematic having a PROVIDES which is the same as the underlying package variant Mar 27 15:52:35 ynezz: still, it's just like any other target switch, it's just the first time right? Mar 27 15:52:51 "make clean; make" should still be ~same for both Mar 27 15:53:05 (nasty for build testing of course, but for users...) Mar 27 15:53:37 make clean? Mar 27 15:53:43 this removes everything no? Mar 27 15:53:50 no, leaves toolchains Mar 27 15:54:01 make dirclean removes toolcahins and rebuilds them Mar 27 15:54:10 ah, ok Mar 27 15:54:22 blogic: https://git.openwrt.org/3a8dbcf5c2f3c71240365006f8dae13f79f729b1 <- nice typo :) Mar 27 16:23:47 jow: sorry - I had to get away from it all & walk the dog Mar 27 16:24:26 I'll create a 'nojson' and 'json' and see how that goes. Mar 27 16:25:29 the recursive deps has been 'muted' by https://github.com/ldir-EDB0/packages/commit/8ae907d270915a863dfc42b2e90bd99188d87266 Mar 27 16:25:49 ah ugh Mar 27 16:27:00 but it nojson/json doesn't solve it I'm going to stop. Mar 27 16:27:11 if Mar 27 17:07:19 Does the CPE210v3 make DHCP on the ethernet port after flashing? Mar 27 17:07:47 should Mar 27 17:10:26 it should just behave like any one-port Mar 27 17:12:40 thanks, I was unsure cause it was not written in the commit there support was added :) Mar 27 17:13:38 I'd say that's standard for a one-port, but then somebody will find an example where it's not ... Mar 27 17:26:39 jow: you are a steely-eyed missile man Mar 27 17:27:03 I'm not going into space unless you're on the console in mission control! Mar 27 17:29:06 ynezz: was it you who came up with a fancy way to import a package into packages feed retaining history? I want to do the opposite..migrate a package feed package into base (jansson) Mar 27 17:30:11 git filter branch or such Mar 27 17:30:21 already paged that out Mar 27 17:32:24 and I'm not sure if doing the opposite makes sense Mar 27 17:35:39 unfortunately to build nfttables with json support it needs jansson Mar 27 17:37:33 and people are beginning to fiddle with nftables Mar 27 17:38:45 the existing nftables package builds without json support... it can be enabled as a build time option where it has the dependency on jansson in the packages feed. Mar 27 17:39:09 but there is no 'nftables-with-json' version of the package available. Mar 27 17:40:53 I'm not a fan of ADDING things to base but I don't see an easy solution to that within my ability. Mar 27 17:47:48 ldir, how big is jansson? Mar 27 17:48:57 HUUUUGE ;-) -rw-r--r-- 1 kevin staff 25626 27 Mar 14:10 ./packages/jansson_2.12-1_x86_64.ipk Mar 27 17:49:24 >x86_64 Mar 27 17:49:54 well, time for a mini json library then Mar 27 17:50:19 26K Mar 27 17:52:47 vs libjson-c which is already in base -rw-r--r-- 1 kevin staff 27911 26 Mar 18:59 ./base/libjson-c4_0.13.1-1_x86_64.ipk Mar 27 17:52:51 28K Mar 27 17:53:33 mmmm. Mar 27 18:05:41 so we need to fit a json-c api shim on top of jannson into those two kilobytes :) Mar 27 18:06:18 f00b4r0: i saw it and hit ctrl+c 1/2s too late Mar 27 18:06:27 hehe :) Mar 27 18:06:48 https://github.com/openwrt/packages/pull/11648 Mar 27 18:06:55 * blogic starts looking at this now Mar 27 18:08:52 whois bkpepe ? Mar 27 18:10:48 ah turris Mar 27 18:10:54 6 six make a dozen Mar 27 18:11:01 2 six make a dozen Mar 27 18:22:10 jow: so 1) are you serious? 2) what does that mean in reality? Mar 27 18:23:34 ldir: 1) yes, somewhat 2) something like a libjson-c-jansson which looks like json-c to apps (compile time is enough, must not be abi compatible) but actually delegates all calls to jansson Mar 27 18:23:59 ldir: idea is to allow migrating all of core to jansson without having to refacture everything Mar 27 18:25:39 both libraries appear to use refcount based memory management so it might be easy to map the json-c api onto jansson Mar 27 18:26:02 it could be as simple as merely redirecting the respective functions Mar 27 18:26:33 this is from a very cursory look at https://jansson.readthedocs.io/en/2.11/apiref.html, I might have missed some important details Mar 27 18:28:59 is this what we're talkinng about? https://github.com/akheron/jansson Mar 27 18:29:02 (out of curiosity) Mar 27 18:29:16 yep Mar 27 18:29:20 :) Mar 27 18:29:31 not sure of "akheron" is the actual upstream but that library, yes Mar 27 18:30:01 it seems so, but that was just a quick online search Mar 27 18:30:15 http://www.digip.org/jansson/ < redirected from here :) Mar 27 18:35:29 meh, seems jansson does not provide a proper incremental parser Mar 27 18:35:42 which is qite unfortunate Mar 27 18:36:55 * ldir hopes that at some point in the near future there will be some words that he understands :-) Mar 27 18:37:32 the main difference, functionality wise I see between jannson and json-c are: Mar 27 18:37:51 btw https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=37d9cd9c0d6042bb1567ddda2c1600337333866c works for me. Mar 27 18:38:03 - json-c allows parsing huge json piece by piece while jansson requires the complete document input to be available at once Mar 27 18:38:29 - jansson supports various "pack" or "printf" like functions to easily produce json from values Mar 27 18:38:39 nftables heavily relies on the latler Mar 27 18:38:47 our openwrt userland heavily relies on the former Mar 27 18:39:02 the rest is more or less the same, just slightly different apis Mar 27 18:40:37 I personally think that writing such a wrapper/shim/interface whatever you call it is WAY beyond my knowledge & comfort zone at the present time. Mar 27 18:41:16 I was trying to help out someone on the forum who is a little frustrated by the lack of nft json support. Mar 27 18:41:37 thats why we never help users ;) Mar 27 18:41:46 xD Mar 27 18:41:56 one learns as one goes lol Mar 27 18:42:09 I really hope that's a joke Mar 27 18:42:15 of course the spoiled mvebu crowd doesn't care about such issues Mar 27 18:42:20 wahts 30K after all Mar 27 18:42:26 oi oi:-) Mar 27 18:42:44 ldir: it is :) Mar 27 18:43:20 maybe I'm overthinking it, really Mar 27 18:43:30 we should just ship with two json libs and openssl by default Mar 27 18:43:36 yeah the mvebu crowd... :P Mar 27 18:43:54 meet 8M, the new 4M flash limit Mar 27 18:44:20 you mean 16MB ^ Mar 27 18:44:24 :-) Mar 27 18:44:27 right, I forgot Mar 27 18:44:34 That's why I've spent the past few days banging my head against package dependency foo with the idea of producing a package based rather than compile time solution to people wanting nft in a json flavour. Mar 27 18:45:00 :P Mar 27 18:45:14 are we switching to 16 MB already? Mar 27 18:45:16 ldir: yep, it also makes a whole lot of sense to me. Just thinking about when we start shipping nft by defualt Mar 27 18:45:23 people probably exact json fancyness then Mar 27 18:45:38 *expect Mar 27 18:45:40 If you don't want to waste 26K on jansson then don't/can't install nftables-json Mar 27 18:45:57 you're probably right Mar 27 18:46:35 The kernel will have eaten more than that by the time fw4 / nftables becomes the norm. Mar 27 18:47:02 inb4 32MB limit by then ^ Mar 27 18:47:36 * f00b4r0 contemplates replacing SPI NOR chips on some old(er) hardware just to keep them going ;P Mar 27 18:47:53 kernel 5.4 is already killing my EA 6350 because of some stuff i added... Mar 27 18:48:16 No one is forcing you to install nftables-json.... well, not yet ;-) Mar 27 18:49:48 speaking of fw, I think I asked before but is there a particular reason why by default synflood protection doesn't apply to forwarded ports? Mar 27 18:50:10 f00b4r0: that would be a question for blogic Mar 27 18:51:00 fw3 is modelled after the dualstack uci firewall which was derived from the shell script uci firewall which was implemented as replacement for the awk based firewall by blogic Mar 27 18:51:19 the synflood logic stayed the same ever since Mar 27 18:51:22 nice. Sounds vintage. Mar 27 18:51:25 ;) Mar 27 18:52:06 I think the reasoning was to protect services *on* the router against syn floods Mar 27 18:52:33 probably with various sharing or multimedia services in mind... but that's just speculation Mar 27 18:52:47 I suspect that's the case but it seems like a missed opportunity for increased security for the end users. Especially now that the tickbox "look" like a global setting Mar 27 18:52:55 (in luci) Mar 27 18:55:20 I'm not looking forward to trying to get https://github.com/ldir-EDB0/packages/commit/4012ce77763fd7bb902540a4139242a6d4f1ec25 accepted. Mar 27 18:56:00 ldir: I wonder why it works... Mar 27 18:59:54 If it 'helps' even if you move +nftables after the first +kmod dep it works. if +nftables is first it borks. Mar 27 19:02:14 I suspect it's magic. Mar 27 19:07:24 more like a bug in scripts/metadata.pm Mar 27 19:09:36 * ldir looks ... and screams! Mar 27 19:09:48 hehehe Mar 27 20:51:15 yeahhhh, if swapping orders of those lists does things, that's gotta be a bug in dep generation :) Mar 27 21:19:21 holy crap Mar 27 21:20:05 various archs modify drivers/platform/Kconfig independently. How am I supposed to handle that Mar 27 21:20:39 this is broken. Very very broken Mar 28 00:16:55 blogic: https://github.com/blogic/udrone/pull/9 Mar 28 01:02:10 trying to get a new device added (Linksys WHW03) but I cannot find the DTB, although I've been able to get the FTD from U-Boot. Is there any other way to get that information? Mar 28 01:13:59 you can decompile it via dtc from sysfs (the result isn't pretty though) Mar 28 01:14:07 https://unix.stackexchange.com/questions/265890/is-it-possible-to-get-the-information-for-a-device-tree-using-sys-of-a-running Mar 28 01:17:08 interesting... I do have access to the OS running, it is based on QSDK also based on an ancient build of OpenWRT, but it does not have dtc available Mar 28 01:17:14 can I port it somehow? Mar 28 01:17:24 probably, but you don't need to Mar 28 01:17:44 just copy the directories from sysfs and scp them to your x86_64 system Mar 28 01:18:42 you can give dtc any path, it doesn't need to come directly from sysfs of a running system Mar 28 01:19:56 pkgadd I will try that, thanks Mar 28 02:34:21 how to deal with the SUPPORTED_DEVICES list? I got a Linksys WCR3200ACM, the profile is called linksys_wrt3200acm, however the SUPPORTED_DEVICES only include "linksys,rango", which is currently the ALT0 (alternative) device name. Should the profile be called linksys_rango and WCR3200 becomes the alternative name? Mar 28 02:41:51 afaiu, as far as the user is concerned, the only name they're going to see (on the package, the type label, in adverts, while buying it) is wrt3200acm - rango is Linksys' internal name, very pronounced within the code, but not really visible to the enduser anywhere Mar 28 02:43:01 pkgadd: okay, but shouldn't OpenWrt follow the internal names instead of the "branding" names? Mar 28 02:44:56 aparcar: I don't think so, especially not in this case. I can tell you the differences between WRT1200AC v1/ v1, WRT1900AC v1/ v2, WRT1900ACS v1/ v2, WRT3200ACM and WRT32x - but I have no idea at all how they map to mamba, caiman, cobra, rango or shelby, without looking into the DTS Mar 28 02:45:49 given that you own the WRT3200ACM, you should be closer to mvebu - but do you know which is which, based on the code names? Mar 28 02:46:34 a new user certainly won't, Linksys never tells them Mar 28 02:49:42 looking at android they have names like herolte for Samsung S7 and when you want to develop, you use that code names. I implemente thid ALT names in the past to make it easiert for users to find their devices, however as devs you likely know the codename of whatever device your working on Mar 28 02:55:24 I may be wrong (and my opinion doesn't really matter anyways), but I doubt it's as easy, especially in the linksys case. taking the Samsung Galaxy S5 as an example, there are at least k3gxx, klteactivexx, kltechn, klte, kltedv, kltekor, kltekdi, kltechnduo, klteduos, lentislte, s5neolte, kccat6 and kltesprsports hiding behind effectively the same model name - at some point you need to rely on the Mar 28 02:55:30 code names, lacking a better differentiation Mar 28 02:55:46 but in the linksys case, the code names are (imho) very internal Mar 28 02:57:43 I just doubt that if you ask a random linksys-mvebu user (probably even developer) in this channel about a code name other than the one for their own device that they'd be able to identify them **** ENDING LOGGING AT Sat Mar 28 02:59:59 2020