**** BEGIN LOGGING AT Wed Feb 19 02:59:57 2020 Feb 19 09:30:57 am0rphis: is the RU version actually different in this case? Feb 19 09:41:30 blogic, morning Feb 19 09:42:17 coming back to the patch set for mvebu, i've refreshed it with the sfp patches included Feb 19 10:07:15 ok Feb 19 10:07:31 can you send it over ? i'll try to look at it next week Feb 19 10:20:24 blogic, sure Feb 19 10:20:26 thanks Feb 19 10:20:47 config needs a bit of love but the rest seems to be ok Feb 19 10:22:15 mail sent Feb 19 10:27:09 jow: I just tired using luci.fs.exec_direct (so I can get a useful timeout message from curl instead of a not very useful object eith error code 6) but I just get permission denied. Is this going via yet another file permission? I've already got extended acls ala https://paste.centos.org/view/78f98f4b Feb 19 10:28:25 (and what's the difference between /usr/share/acl.d/* and /usr/share/rpcd/acl.d ? is this the duplication of ubus having a rpcd as well as direct ubus services again?) Feb 19 11:13:08 karlp: the latter existed from the beginning and added acls specifically for rpcd (only rpcd itself honours these acls for the methods it hosts) Feb 19 11:13:27 karlp: the former was added to ubus itself eventually Feb 19 11:14:19 karlp: you need "cgi-io": [ "exec", "read" ] in "write": { .. } for read_direct() / exec_direct() to work Feb 19 11:20:05 karlp: or simply "cgi-io": [ "*" ] to follow your "superuser" example Feb 19 11:21:23 commit messages - WHY WHY WHY! WHY are you doing such a thing Feb 19 11:25:32 (the code 6 I was getting was actually curl's timout response when you have -s, not a ubus timeout code) Feb 19 11:25:42 what else is cgi-io responsible for? Feb 19 11:27:15 karlp: it offers exec/read/write to files and a sysupgrade archive download action Feb 19 11:27:18 ldir: ? Feb 19 11:28:06 and cgi-io doesn't have it's own ubus endpoind then Feb 19 11:28:22 no, its a plain cgi program Feb 19 11:28:38 which is why it's in the rpcd/acl.d dir then Feb 19 11:28:49 but it talks to rcpd's session/access method to figure out whether it is allowed to handle actions Feb 19 11:29:02 it also uses rpcd's session ids Feb 19 11:31:09 doesn't really feel like it can be documented on the ubus techref wiki page then... Feb 19 12:42:01 hi all, do i need both or is enough one of Packages.sig/Packages.asc to pass check_signature? Feb 19 12:44:46 you only need .sig Feb 19 12:47:31 thanks Feb 19 12:58:14 jow: ping - do you by any chance have "system load" luci_stats graph enabled on a system? My graphs don't look right and I'm seeing identical min, avg, max, last values for 1, 15, 5 minute load averages. Feb 19 12:58:24 ldir: yes Feb 19 12:58:46 they look more or less expected to me Feb 19 13:00:03 do you see a 1 minute outline and then 5 & 15 minute shaded areas? Feb 19 13:00:08 yes Feb 19 13:01:25 Hmm, that suggests my data collection is faulty. I'm seeing very strange values for 'interfaces' as well. Feb 19 13:03:42 ldir: actually... I am seeing the same broken behaviour now Feb 19 13:04:32 ah, ok. Not just me is 'good' Feb 19 13:07:39 ldir: seems like a bug in the rrdtool graph command generator Feb 19 13:07:44 will take a look Feb 19 13:08:11 Thanks Feb 19 13:12:28 ldir: please try this: http://sprunge.us/z4rxBm Feb 19 13:13:08 will do... Feb 19 13:19:36 It has certainly improved my interfaces graphs.... they look much more sensible. Still not convinced the system load is quite correct. 5 min graphs looks missing to me. Feb 19 13:20:09 The chosen colours don't make it easy :-) Feb 19 13:21:21 it's definitely there Feb 19 13:22:22 https://imagebin.ca/v/5CsDy9niafmb Feb 19 13:25:35 my system is so lightly loaded there's no difference between the 5 & 15 min graphs... well that's my theory Feb 19 13:26:30 anyway, the change has DEFINITELY fixed my 'interface' graphs, so thank you :-) Feb 19 13:58:41 is opkg using wget in background? Feb 19 14:00:40 indy: no, uclient-fetch Feb 19 14:01:49 :) wget -h and uclient-fetch -h have same output Feb 19 14:02:20 Yes, because it's not wget Feb 19 14:14:17 because wget _is_ uclient-fetch, unless you isntall the wget package. Feb 19 14:17:36 but https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libopkg/opkg_download.c;h=f9e7e98386dbb5d2e45f08e9dd54a004ce0033e2;hb=HEAD#l94 names wget not uclient-fetch Feb 19 14:17:38 :) Feb 19 14:18:39 yes, becaus it used to be busybox wget, and they didn't want to find every single caller of "wget" and change it. Feb 19 14:18:53 so "wget" will get you soemthing that is "somewhat" compatible with wget. Feb 19 14:19:22 and opkg can be used in places that don't have uclient-fetch Feb 19 14:27:56 root@jj:~# which wget Feb 19 14:27:56 /usr/bin/wget Feb 19 14:27:56 root@jj:~# ls -lh /usr/bin/wget Feb 19 14:27:56 lrwxrwxrwx 1 root root 18 Feb 15 22:43 /usr/bin/wget -> /bin/uclient-fetch Feb 19 14:29:11 I think it changed between 18.06 and 19.07 ... Feb 19 14:29:57 I had some trouble with that because uclient-fetch wget does not support Link-local IPv6 addresses Feb 19 14:30:05 * karlp laughs Feb 19 14:30:09 PaulFertser: ^^^ Feb 19 14:30:39 I'm now just using "busybox wget" as command directly in my downstream project Feb 19 14:31:17 :-D Feb 19 14:31:53 my local build here has somehow ended up with curl _and_ gnu wget and uclient-fetc Feb 19 14:32:48 karlp: oh :( so all the folks telling me about problems with LL being relatively common were right. Feb 19 14:32:49 unfortunately we still support tiny devices downstream, so no space ... Feb 19 14:33:20 PaulFertser: most of us don't _try_ to make up problems :) Feb 19 14:33:25 karlp: and with uclient specifically, it does some trickery with command line and that's where it's probably breaking it. Feb 19 14:33:26 uclient-fetch wget does not know the "%" modifier before the interface at all Feb 19 14:33:40 many naive implementations don't Feb 19 14:33:47 adrianschmutzler: it should be just passing it verbatim to getaddrinfo Feb 19 14:33:55 There's nothing to know about it Feb 19 14:34:19 has getaddrinfo actually always "done the right thing"? was ther a time when it needed to try parsing first? Feb 19 14:34:32 it==all the programs that fail at LL addresses Feb 19 14:34:41 I do not remember the details, it's been some time since I've checked it... Feb 19 14:34:48 link-scoped, rather than link local, I should say Feb 19 14:35:16 I had an impression getaddrinfo always supported link-scoped properly. Feb 19 14:35:22 I understood that it would not be easy to patch it, so I wen't for busybox wget ... Feb 19 14:35:46 is it because of people trying to use AF_INET[6] vs UNSPEC? Feb 19 14:35:47 Probably it is easy to fix for someone familiar with the code. As no parsing or additional tricks are really needed. Feb 19 14:41:37 uclient uses usock_inet_timeout() Feb 19 14:41:56 and passes the part between [] in the url literally to it Feb 19 14:42:02 https://git.openwrt.org/?p=project/libubox.git;a=blob;f=usock.c;h=0ce5390434d2ccae31bd0d9ec49c7e74e2e47c23;hb=43a103ff17ee5872669f8712606578c90c14591d#l137 Feb 19 14:42:07 that uses getaddrinfo already Feb 19 14:44:17 using strace uclient-fetch http://[fe80::12ef:48e1:7027:6ad3%br-lan]/ Feb 19 14:44:29 I see connect(6, {sa_family=AF_INET6, sin6_port=htons(80), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "fe80::12ef:48e1:7027:6ad3", &sin6_addr), sin6_scope_id=if_nametoindex("br-lan")}, 28) = -1 EINPROGRESS (Operation in progress) Feb 19 14:44:51 so unless I misunderstood the discussion here, there is no problem with scope ids Feb 19 14:45:07 at least not with parsing such addresses Feb 19 14:47:08 or it's been fixed since andrian tried it last? Feb 19 14:47:20 Thank you jow for checking! Feb 19 14:47:21 but yes, certainly looks like no problems Feb 19 14:47:26 I'm just trying to reproduce, will take a moment Feb 19 14:49:42 overall I still don't like uclient though... the onyl reason it exists is because we needed some wget-esque programm that dlopens ssl support at runtime to make it optional Feb 19 15:02:29 Seems to work with 19.07.0 ("Connecting to" status suppresses the interface-id, though): Feb 19 15:02:49 "/bin/uclient-fetch http://[fe80::1%br-mesh]:2342/keyxchangev2data -O /tmp/3.txt" Feb 19 15:02:55 "Downloading 'http://[fe80::1%br-mesh]:2342/keyxchangev2data'" Feb 19 15:03:01 "Connecting to fe80::1:2342" Feb 19 15:03:24 So, something must have changed since my last test :-) Feb 19 15:09:00 Though I do not really see what that would be ... Feb 19 15:15:25 Interesting, for some servers it works, for some I get error 400 Feb 19 15:15:29 busybox always works Feb 19 15:16:34 I will have a closer look when I have more time for that ... Feb 19 15:42:26 did people see my uci-defaults/50-dnsmasq-migrate-resolv-conf-auto.sh patch? current master isn't cleaning it up after it runs Feb 19 15:43:29 russell--: fwiw, it's tracked on https://patchwork.ozlabs.org/patch/1239776/ Feb 19 16:46:37 has anyone noticed that lua's math.random() always returns zero on the first invocation in our lnum patched version? Feb 19 16:47:03 it doesn't really matter much for me, I'm jsut doign some jittering withit, but, wasn't what I was expecting :) Feb 19 16:50:26 karlp: not quite random Feb 19 16:54:42 it's like it's getting the same seed everytime actually Feb 19 16:55:00 guess I have to manually read dev/blahrandom and seed it manually on start every time Feb 19 16:55:27 looks like my hsot lua has the same sequence too, just didn't start with 0, so didn't _look_ as bad. Feb 19 16:55:30 oh well :) Feb 19 16:57:34 it is a prng with a fixed seed Feb 19 16:57:45 the manuel also states that you must seed it yourself Feb 19 17:03:19 well, I didn't find that in the 5.1 manual itself, only whenyuou read between teh lines that it's calling C library random, Feb 19 17:05:12 ahh, "programming in lua" mentions this, but not the manual. ohw ell :) Feb 19 18:06:58 ping jow Feb 19 18:10:01 ping ldir Feb 19 18:45:10 rmilecki ping Feb 19 19:03:19 I would like to test a new openWRT image on a bcm53xx router (with CFE) without flashig it ... Not sure which image though (vmlinux? vmlinux.elf? zImage? zImage-initramfs?) I think I am missing something - any help would be appreciated :) Feb 19 19:05:58 I am trying to boot it over tftp (network works) Feb 19 19:10:33 i.e. CFE> boot -tftp -raw -max=6950488 192.168.10.100:/zImage-initramfs Feb 19 19:11:11 but it stucks Feb 19 19:11:15 Loader:raw Filesys:tftp Dev:eth0 File:192.168.10.100:/zImage-initramfs Options:(null) Loading: TFTP Client. ........... 262144 bytes read Entry at 0x20000000 Feb 19 19:11:15 Closing network. Starting program at 0x20000000 Feb 19 19:16:17 RobertP: use pastebin for logs plz ;) Feb 19 19:21:32 will do - full logs? Feb 19 19:22:07 RobertP: yes Feb 19 19:22:33 RobertP: initramfs is the correct image to try. But zImage should try to boot too, just panic later when trying to mount rootfs. Feb 19 19:22:46 RobertP: since it's smaller it might work "better". Feb 19 19:23:09 https://pastebin.com/qwui1NGh Feb 19 19:24:33 looks like all images I have tried loads only part of the file (262144 bytes read) Feb 19 19:24:47 RobertP: try booting uncompressed (vmlinux) Feb 19 19:24:53 Just for the kicks Feb 19 19:25:10 Is 0x20000000 matching the address expected by the kernel? Feb 19 19:25:22 how can I check it? :) Feb 19 19:25:59 By reading the relevant parts of Makefile, probably linker scripts etc Feb 19 19:35:26 PaulFertser thanks - will try to look, but right now I have no idea what to look for Feb 19 20:03:33 hey! can anyone tell me why a package that it's built properly and generates a .ipk may not get installed in the final image? Feb 19 20:07:36 aleksander_m: if it has =y in config it should be installed Feb 19 20:08:12 it has =y, that's why I'm a bit curious what could be happening Feb 19 20:08:39 aleksander_m: probably the ipk file is empty too? Feb 19 20:09:09 no, it isn't, because I can install it *afterwards* in the system once I've flashed the image that doesn't have the package Feb 19 20:09:17 it's all a bit weird Feb 19 20:15:15 oh shit, I'm stupid Feb 19 20:15:39 I was installing builds I built yesterday, no wonder they didn't have the package I added today Feb 19 20:15:41 We all are occassionally. Feb 19 20:16:07 :D Feb 20 00:51:24 rmilecki: It seems "kernel: rewrite run_parsers_by_type() to use add_mtd_partitions()" causes missaligned partitions on some boards, according to comments on github Feb 20 00:52:08 I can reproduce this here (jffs2 is missaligned by 0x20000), but i'm unable to point on whts causing this **** ENDING LOGGING AT Thu Feb 20 02:59:57 2020