**** BEGIN LOGGING AT Mon Mar 23 02:59:58 2020 Mar 23 03:08:41 russell--: what kind of change are you proposing? Mar 23 03:08:55 did I forgot to add geode in my patch? Mar 23 03:09:52 oh damn I actually did, sorry for that! Mar 23 04:55:12 russell--: if you don't mind I'll send a patch to openwrt-devel Mar 23 06:31:35 aparcar[m]: please do Mar 23 08:52:02 ynezz: thanks for responding to the bug reports Mar 23 09:02:22 Hauke: I got this the first time I tried to build after the 8.4.0 commit - I do have CONFIG_PKG_FORTIFY_SOURCE_2=y Mar 23 10:20:46 russell--: are you sure about the line +FEATURES += pci usb gpio? Mar 23 10:21:01 I think in the previous version they used := Mar 23 11:49:31 aparcar[m]: it didn't work without it Mar 23 11:49:39 tmn505 suggested it Mar 23 11:57:42 one will add to linux/x86/Makefile:FEATURES:=squashfs ext4 vdi vmdk pcmcia targz fpu boot-part rootfs-part Mar 23 11:58:26 the other will replace with linux/x86/geode/target.mk:FEATURES:=pci usb gpio Mar 23 12:00:23 we could probably do without pcmcia for the alix ;-) Mar 23 12:00:52 My guess is that it if you're going to override it should have boot-part rootfs-part squashf ext4 Mar 23 12:01:20 and maybe fpu, just guessing at what that does Mar 23 12:01:23 that's based on what changes I see in cb007a7bf6199ebca89f79c8ee5f9b1807a0c5b0 Mar 23 12:03:25 I assume the features are more controlled due to space constraints. But I really am guessing! Mar 23 12:04:25 holycrap, what does DUMP do? Mar 23 12:08:31 i am being asked for SCSI_FDOMAIN_ISA, I2C_AMD_MP2, PCENGINES_APU2 kernel configs too, for geode Mar 23 12:10:09 keine ahnung Mar 23 12:10:26 My favourite bit of German :-) Mar 23 12:18:45 * russell-- wonders what CONFIG_ALIX does, since it's disabled in target/linux/x86/config-5.4 Mar 23 13:35:53 jow: if you still want some lua server side endpoints, how do you use menu.d stuff? https://paste.jvnv.net/view/LTo5n Mar 23 13:36:23 I've looked at all the menu.d/*.json files in luci master, and only see type: cbi, view, template and "firstchild" Mar 23 13:37:12 karlp: { "type": "call", "module": "luci.controller.someoldthing", "function": "action_diag" } Mar 23 13:38:51 module may reside everywhere within /usr/lib/lua and must not necessarily be placed in the controller dir Mar 23 13:39:10 and then the controller just... drops the index() function? Mar 23 13:39:32 that just becomes any requireable module with an accesible function then? Mar 23 13:39:40 correct Mar 23 13:41:01 don't need the module(blah, package.seeall) anymore then either, Mar 23 13:41:09 most likely not Mar 23 13:41:26 and should probably not expect that you can "just call" things like luci.http.blah I guess... Mar 23 13:41:33 don't fully know offhand, but essentially the value of "function" is looked for in whatever is returned by require() Mar 23 13:41:55 so it could be a simple lua file returning a table of functions or something Mar 23 13:41:56 * karlp suspects he'll just leave it as a regular controller for now, with a modern js view. Mar 23 13:42:09 yeah, "regular" lua modules :) Mar 23 13:42:15 yeah, whatever you call still needs to do something meaningful Mar 23 13:42:28 at the very list outputting something using luci.http.write/( Mar 23 13:42:32 *write() Mar 23 13:42:54 yeah, I have existing stuff, just if I'm editing things at the moment, I'm trying to migrate them as I do it. Mar 23 13:44:32 I want to do some whitespace trimming on save, what's the "right" way of calling the normal function after I've trimmed? like I can implement o.write(), (on a js cbi option) but where's the underlying one? Mar 23 13:45:48 either this.super('write', [ arg1, arg2, ... ]) or form.Value.prototype.write.call(this, arg1, arg2, ...) or form.Value.prototype.write.apply(this, [arg1, arg2, ...]) Mar 23 13:46:59 the first variant will actually call the super class implementation of the function, so unless you extended some form.Foo into a new class, it'll call form.AbstractValue.write() which is sufficient for most cases Mar 23 13:47:27 the other two variants will call the write function of a specific implementation with your current instance context Mar 23 13:47:43 for ordinary write() override, all three should be equivalent Mar 23 13:48:45 one day I might even look at the type handling to do it optionally all the time :) Mar 23 13:49:26 had an init script that auto swallowed the whitespace, and some uci stuff that preserved it, fun times Mar 23 13:59:35 Hello, Anyone have openwrt working on edge-core ECW5410-L systems? Mar 23 14:00:37 * ldir puts everyone on standby for his 1st silly question of the day Mar 23 14:01:42 ldir: no we wont send face masks Mar 23 14:02:24 just soak your bandana in moonshine, duh! Mar 23 14:02:57 I'm looking at libnftnl and compile both with and without "--without-json-parsing" - I don't see any size difference in the resultant *.so or *.a files. This surprises me. Mar 23 14:07:41 size doesn't seem to be a compelling reason to compile without Mar 23 14:08:44 https://bugs.openwrt.org/index.php?do=details&task_id=2821 Mar 23 14:12:06 blogic: ;) Mar 23 14:17:38 hah! --without-json-parsing doesn't even appear to be a supported configure option Mar 23 14:17:55 * ldir peers into the rabbithole Mar 23 14:18:46 hrm, left some hardware at the office, so trying x86 generic in qemu, but I get thing slike "Failed to find log object: Not found" when I try and run logread for instance? is there some basic things I'm missing? haven't even tried to get networking yet. Mar 23 14:22:20 if I import the ext4 image into a new machine in virt-managerr it works, but I don't even have an eth0 :| Mar 23 15:02:54 * ldir gets back walking t'spaniel Mar 23 16:09:48 Hi all, why does ifstatus lan never have an ipv6-address array filled? Mar 23 16:11:43 I suspect it is because that section is for statically assigned addresses. Note the section "ipv6-prefix-assignment" Mar 23 16:12:45 so, doing anythign in qemu-system-x86_64 -M q35 never worked for me, but importing an existing disk image as the combined-ext4.img, and, importantly, switching the nic from e1000 to virtio and now it all works nicely. Mar 23 16:15:29 thanks ldir Mar 23 16:15:39 I'm still getting the hang of IPv6, I'll do some more research Mar 23 16:16:34 so, i don't see a MyNet N600 device in the ath79 menuconfig; does it need adding? Mar 23 16:46:49 (looking like it does) Mar 23 16:54:15 jow: works nicely thanks: https://paste.jvnv.net/view/eBNJr Mar 23 16:54:49 (are there any value fields where you'd _want_ leading/trailing whitespace kept?) Mar 23 17:30:44 jow: ping - packaging assistance please Mar 23 17:36:07 ldir: pong Mar 23 17:36:49 karlp: very little, at some point I thought about auto-trimming that can be optionally disabled but I decided against it Mar 23 17:37:50 dude! :-) I'm 'playing' with the nftables package at the moment.. so I understand correctly.. it has the option of being built with json support, disabled by default. So does that mean the only package available from the feed has json disabled? Mar 23 17:38:09 ldir: yes Mar 23 17:38:23 ldir: I've no objections to enable json Mar 23 17:38:33 ldir: problem is that it pulls in yet another json library iirc Mar 23 17:38:34 even space? Mar 23 17:38:43 and that library happens to be out of tree Mar 23 17:38:45 yes it does pull in jansson Mar 23 17:38:49 whihc sucks Mar 23 17:38:52 Ahh! Mar 23 17:39:08 because eventually we need to ship with two redundant json libraries Mar 23 17:39:37 or patch our entire userland to use jannson or patch nftables to use json-c or come up with a compatibility shim Mar 23 17:39:58 * ldir head-desks Mar 23 17:40:12 its the same clusterfuck as netlink Mar 23 17:40:31 every project invents its own netlink helper library Mar 23 17:40:38 which is why it hasn't been done yet. Mar 23 17:40:45 correct Mar 23 17:42:02 Can I work around this by having a package variant ? Mar 23 17:42:27 it's the road I've been travelling so far 'cos I wasn't sure about enabling json by default Mar 23 17:42:32 ldir: one thing worth testing (feed<>core depend issue aside) would be builting nftables and static libjannson with -ffunction-sections Mar 23 17:42:36 then link with gc-sections Mar 23 17:42:47 and see how much the nftables executable size actually increases Mar 23 17:42:58 maybe its just a few K and we can avoid runtime-depending on libjannson Mar 23 17:44:11 interestingly, jansson seems to be even smaller than libjson-c Mar 23 17:44:33 maybe a libjson-c api compat layer on top of jannson would make sense indeed Mar 23 17:44:54 the other way around is not feasible since json-c only offers a subset of jansson functionality Mar 23 17:45:10 but it's bigger?!!! Mar 23 17:45:10 main culprint are the formatting helpers Mar 23 17:45:15 sure? Mar 23 17:45:37 https://downloads.openwrt.org/snapshots/packages/mips_24kc/base/ -> libjson-c4_0.13.1-1_mips_24kc.ipk ~ 19.8KB Mar 23 17:45:40 What about using iptables-nft instead? Mar 23 17:46:00 https://downloads.openwrt.org/snapshots/packages/mips_24kc/packages/ -> jansson_2.12-1_mips_24kc.ipk ~ 18.3KB Mar 23 17:46:06 dengqf6: dead-end Mar 23 17:47:58 ldir: uncompressed its ~33K for jannson vs. ~42K for json-c on mips_24kc Mar 23 17:48:51 Hmm, ok this wasn't the simple low hanging fruit I was looking for. Mar 23 17:49:02 ldir: :) Mar 23 17:49:54 as a very first step I'd try to convince the feed people to allow jansson into base Mar 23 17:50:16 At least I've found out why https://bugs.openwrt.org/index.php?do=details&task_id=2821 is like it is Mar 23 17:50:29 then we can at least package nftables normally with a dynamic dependency on jannson Mar 23 17:50:43 and evnetually optimize (or simply live with it when hw became big enough) Mar 23 17:51:30 I'm wondering if it's really a case of 'if you're interested in nftables then you have the space' ! Mar 23 17:51:57 just go straight to bpf packet filtering ;) Mar 23 17:53:16 stintel: you're doing what my wife does when trying to choose between 2 things... she expands the choices! STOP IT! Mar 23 17:54:00 * stintel gd&r Mar 23 18:06:43 aargghhh - ok what am I doing wrong here https://paste.ubuntu.com/p/t6w9svjSrv/ Mar 23 18:07:50 if a copyright line was previously "# Copyright (C) 2016 - 2017 Stijn Tintel" and I only worked on it again in 2020, can I change it to 2016 - 2020 or do I need to 2016 - 2017, 2020 ? Mar 23 18:15:04 ok I'm just going for the former Mar 23 18:16:21 IANAL Mar 23 18:16:43 :) Mar 23 18:19:20 IEANACL Mar 23 18:19:51 tmn505: ping Mar 23 18:31:20 build #301 of mvebu/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mvebu%2Fcortexa53/builds/301 Mar 23 18:35:49 aparcar[m]: pong Mar 23 18:39:48 tmn505: there seem to be problem with the x86 images when using within virtualbox Mar 23 18:40:03 tmn505: do you have an idea what could be the problem? it does work fine in qemu Mar 23 18:40:10 https://user-images.githubusercontent.com/5343595/77314721-2b997300-6d41-11ea-97fd-2ac37f0cf65b.png Mar 23 18:40:21 this is a users screenshot Mar 23 18:41:44 ldir: can't spot a mistake either Mar 23 18:41:47 didn't test yet any image after transition. Mar 23 18:41:52 ldir: rm -r tmp/ ? Mar 23 18:42:12 aparcar[m]: it worked long ago Mar 23 18:42:58 aparcar[m]: I'm preparing noe bigger hdd to run compilation and will test them Mar 23 18:44:17 tmn505: okay thank you, please keep me updated Mar 23 18:44:53 ldir: IEANACL? Mar 23 18:45:56 aparcar[m]: betting it's something like 'i effectively am not a copyright lawyer' or sth Mar 23 18:47:16 Borromini: thanks ;) Mar 23 18:47:55 tmn505: does the error message look like anyhting to you? maybe I can also poke around with the setup Mar 23 18:48:52 aparcar[m]: is that f2fs image? Mar 23 18:49:04 i assume yes Mar 23 18:50:22 aparcar[m]: yw. ldir is that brexit affecting your brain already? :P Mar 23 18:51:22 aparcar[m]: I meant squashfs, the f2fs is overlay. Mar 23 18:54:58 tmn505: yes squash Mar 23 18:55:43 aparcar[m]: I saw such errors on real ssd which had not enough blocks for relocation, but that is virtual one. Mar 23 18:57:04 tmn505: ext4 works fine btw Mar 23 18:59:00 russell--: thanks again https://github.com/openwrt/openwrt/commit/6f01d3334ef3834d888dc91b35e51524439b34d1 Mar 23 18:59:03 migth be that the padding is incorect Mar 23 19:01:05 build #297 of x86/geode is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeode/builds/297 Mar 23 19:01:27 aparcar[m]: can you ask the user to build images after deleting this line: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x86/image/Makefile;h=c2961e5b9c9b8a6421b7ca5d6e16ef0145137b28;hb=HEAD#l121 Mar 23 19:02:22 tmn505: I'll test it here locally. Will update you in a few minutes Mar 23 19:09:29 tmn505: same error Mar 23 19:11:46 then I don't have any ideas ATM, will report back after testing. Mar 23 19:12:04 tmn505: thank you! Mar 23 19:40:07 aparcar[m]: Borromini was pretty close - 'especially' am not a copyright lawyer Mar 23 19:40:13 Borromini: yes Mar 23 20:05:21 ldir: hehe Mar 23 20:25:31 ldir: should I create a 9.3 patch or did you fix it on mac os x? Mar 23 20:25:48 ????? Mar 23 20:27:19 ldir: wasn't there a problem with gcc 8.4? Mar 23 20:28:20 no, I was saying that both 8.4 & 9.3 are working fine for me on macos Mar 23 20:28:44 it was stintel who had some problem with 8.4 Mar 23 20:28:51 ldir: did gcc 8.3 not work on macos? Mar 23 20:28:51 ldir: oh nevermind then :) Mar 23 20:29:12 under linux... well if you will use some obscure OS I mean what do you expect Mar 23 20:29:53 o.O Mar 23 20:41:35 UK now in pretty much full lockdown Mar 23 20:43:26 Hauke: no, all is well AFAIK - it was stintel who reported a headers issue with 8.3.. I'm assuming under some form of linux. Mar 23 20:45:57 8.3.0 worked fine, it's the bump to 8.4.0 that caused some failure here. might be resolved by nuking my build_dir completely Mar 23 20:47:21 * ldir hands stintel a 'make dirclean' Mar 23 20:54:21 aparcar[m]: how do you run openwrt in qemu? I've got it running as a full machine with virt-manager, but just qemu-system-x86_64 -M q35 -drive file=blah-combined-ext4.img doesn't give me anything useful, I get a broken log and network interfaces with no connectivity Mar 23 20:57:57 stintel: I haven't seen such a problem, I asume it is related to some old stuff Mar 23 20:58:06 some left overs from gcc 8.3 Mar 23 21:05:37 stintel: yes that usually does the trick for me Mar 23 21:06:11 * mamarley always does a "make dirclean" after a GCC update as a matter of course. Mar 23 21:06:17 karlp: I use ./scripts/qemustart x86 64 which ends up in a working machine, however did not try network or anything really Mar 23 21:16:10 why is it that all the code around mikrotik devices has to be butt ugly ;P Mar 23 21:18:34 yeah seems to be ok now Mar 23 21:18:59 all the more reason to finish autobuilds for all my devices that I never run into this crap again Mar 23 21:19:03 always such a waste of time Mar 23 22:43:55 hi, is there any way/option to force the bootargs in the dts kernel file and ignore the bootargs from Uboot? Mar 23 22:45:19 it's an mvebu board, kernel 4.19 Mar 23 22:46:08 stintel: check out chef.libremesh.org if you need custom images ;) Mar 23 22:46:48 danitool: git grep bootargs target/linux Mar 23 22:47:03 it's in menuconfig too isn't it? Mar 23 22:47:48 ynezz: please let me know if you have some time to discuss another revision of the JSON patch Mar 23 22:48:12 I found a bug for devices not using the generic.mk image script, however thats rather easy to fix Mar 23 22:52:12 aparcar[m]: I already have a fully automated build pipeline, I'm using many custom options, not just custom packages, that's not going to be sufficient Mar 23 22:54:02 just need to expand it so that it also build if I push to branches of my staging tree or fork of the packages feed Mar 23 22:57:23 karlp: I've something like this in my tree for QEMU http://paste.ubuntu.com/p/6bzYWbgkDF/ but it needs some refresh (probably the LAN part doesnt work anymore) as I started using QEMU from Git recently Mar 23 22:57:41 stintel: can you elaborate on that system? seems like something every dev wants to have Mar 23 22:58:14 ynezz: yeah, the script in the tree that just starts sudo'ing ip addresses is... not encouraging. Mar 23 23:00:11 aparcar[m]: I'm running OVH CDS locally. it's not really user-friendly Mar 23 23:07:25 karlp: I use that script if I don't need network Mar 23 23:10:17 yeah, I don't really see mcuh need for a vm that doesn't have network :) Mar 23 23:10:33 debugging crashing procd for example :p Mar 23 23:10:34 bright side, I figured out the incantations to make it work nicely via virt-manager today finally, so mostly ok now. Mar 23 23:14:43 karlp: document it ;) Mar 23 23:15:13 it's just "use virtio not e1000" Mar 23 23:15:36 going to experiment a bit more with how it behaves when updating the build tree before I start chopping the wiki Mar 23 23:16:18 also, _my_ test requirements for a owrt vm are that it has some sort of networking so that I can debug luci apps and cloud connectivity shit, not the multi interface performance routing stuff Mar 23 23:17:10 good, the more qemu users, the better :) Mar 23 23:21:23 my central VPN router is OpenWrt in qemu, has been for years Mar 23 23:22:16 master x86/64 is seriously hosed. I don't have keepalived, I don't have lxc, both are enabled in my .config Mar 23 23:22:18 wth Mar 23 23:23:53 sigh. images have a different name Mar 23 23:24:00 wonderful Mar 23 23:29:13 ynezz: I had to use: append-rootblock = "root=/dev/mtdblock", in the chosen node, and then it ignored the booloader bootargs Mar 23 23:29:17 stintel: sorry for that Mar 23 23:31:00 not friendly to find this option, but I solved the problem afterall Mar 23 23:39:53 aparcar[m]: soon :) Mar 23 23:42:04 ynezz: sure Mar 23 23:44:33 I wonder if we should store instead of names just type, suffix, filesystem and checksum per image. The name should always be openwrt-[release]--[subtarget]---. **** ENDING LOGGING AT Tue Mar 24 02:59:57 2020