**** BEGIN LOGGING AT Thu Jun 13 02:59:57 2019 Jun 13 04:47:34 on openwrt main status page, section wireless, Associated Stations there is a column 'RX Rate / TX Rate' + Channel bandwidth. RX show 5MHz and TX shows 20MHz . Where is Luci getting this info from ? Jun 13 04:47:52 in my case they should be both 5MHz Jun 13 06:18:44 de4rst: via nl80211 netlink Jun 13 06:18:57 de4rst: compare with iw dev wlan0 station dump Jun 13 06:59:33 for someone has asked about libnl/libnl-tiny, some golang library and namespaces support in kernel: github.com/openwrt/openwrt/commit/fcb41decf6 Jun 13 07:00:18 afaik, it was FatherT Jun 13 07:54:33 Hey, not complaining, just asking... Are there any rough estimates for the next stable openwrt release? Jun 13 07:54:53 airwind: 1-2 month Jun 13 07:55:01 jow: ty Jun 13 11:02:24 xback: hi, could you please check/test https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=d1c5da589588017133f235623c561937814a2bdf ? Jun 13 11:02:42 ynezz: yes. just noticed it thanks! Jun 13 11:03:03 i'll only be able to check it tomorrow Jun 13 11:03:13 currently working on the mvebu issues with 4.14.125 Jun 13 11:03:20 :) Jun 13 11:03:29 sure, no problem, but it would be nice to get this into 19.07 Jun 13 11:04:13 xback: I was looking into it last night but didn't manage to finish it Jun 13 11:04:39 I noticed why I didn't see it Jun 13 11:04:44 xback: looking at the patch causing the issue in linux.git, it seems it was split into 2 patches Jun 13 11:05:00 I didn't select all target flavours during compilation testing Jun 13 11:05:24 xback: upstream commits fc548b991fb0646820f5d3b9db55501f61871748 and 503f9aa9cc97d8563b77ab9ebc1ce78e49697881 Jun 13 11:05:34 stintel: thanks! :) Jun 13 11:05:51 but if I replaced our 403 patch with that, 404 was no longer relevant and then 405 failed, iirc Jun 13 11:06:30 and then looking at it further, it might actually be needed to drop a bunch of our patches and replace them with the upstream accepted versions instead Jun 13 11:06:37 that's where I gave up and went to bed ;) Jun 13 11:11:00 stintel: hi, are you going to bump the targets to 4.19 ? Jun 13 11:11:23 I've registered something like that in some email thread Jun 13 11:11:36 ynezz: I was just thinking to do that for x86 to start Jun 13 11:12:26 stintel: do you've any reason to bump just x86? Jun 13 11:12:59 BTW we've talked about it on the summit and we agreed, that we should bump all targets which have 4.19 support already at once Jun 13 11:13:11 ok then go for it Jun 13 11:13:12 I can build test it if you want Jun 13 11:14:18 I wanted to do x86 just because my main VPN routers are x86 and I wanted to test xfrm-interfaces Jun 13 11:14:28 but I did it with CONFIG_TESTING_KERNEL instead Jun 13 11:15:47 idea is to bump all targets with 4.19 to 4.19 ASAP in order to start the testing Jun 13 11:17:01 since it seemed to me, that you're about to do it, I've left it to you :) Jun 13 11:19:37 I'm on my way back home, so crappy internet access and almost dead battery, but if you could create commit in your staging tree, I could just fire the build test on my server for all those targets and we'll see how it builds Jun 13 11:20:45 just don't want to do the same thing twice :) Jun 13 11:21:32 or we could split the build test between us, there are 13 targets I think we could flip Jun 13 11:23:37 just to avoid more PRs like PR#2112 or PR#2108 Jun 13 11:24:43 ynezz: I would only do it for x86 as explained. I don't have time to work on this during the day due to day job Jun 13 11:24:55 ok, understand Jun 13 11:24:56 so if you do have the time, please do so Jun 13 11:38:46 so I assume, I can skip build test of x86_64, right? Jun 13 11:44:10 x86/64 built for me, but had to disable perf Jun 13 11:44:33 that's one of the tools that doesn't stop breaking :/ Jun 13 11:46:07 perf doesnt build on x86_64? Jun 13 11:48:08 not with kernel 4.19 Jun 13 11:48:34 I lost count on how many times I had to disable perf because it didn't build after some update Jun 13 11:48:44 similar issues with strace Jun 13 11:50:27 maybe we should add a new tag for packages; "PKG_FRAGILE:=1", which then automatically adds them to IGNORE_ERRORS ;P Jun 13 11:50:32 :) Jun 13 12:53:28 hm, how to make target source only? how to disable image generation on ar71xx? Jun 13 12:54:03 I've thought, that it would be tied to BUILDBOT=y config option, but couldn't anything which would allow that Jun 13 12:54:15 s/anything/find anything/ Jun 13 12:54:52 ynezz: add it to FEATURES (also for reference; git log -p --grep="source-only") Jun 13 12:55:18 you might or might not need to touch the target makefile and/or clear tmp/ to make it effective Jun 13 13:01:22 jow: thanks, still can't understand how this works, as source-only is mentioned only in FEATURES but nothing is consuming this feature Jun 13 13:04:22 ok, it's only consumed on buildbot in phase1/dumpinfo.pl Jun 13 13:04:52 correct Jun 13 13:05:10 (I do have to restart/reconfig the buildmaster after that change is life to make it effective) Jun 13 13:06:24 yeah, makes sense Jun 13 13:13:30 is it ok https://git.openwrt.org/c31286e9b93f ? Jun 13 13:27:09 ynezz: ping Jun 13 13:27:29 ynezz: I just checked the patch. some boards are missing (like the RB922 flavours) Jun 13 13:27:53 ynezz: the rb922 for instance gets deleted .. but not re-added in the new function Jun 13 13:29:12 ok, so probably some leftover in that PR Jun 13 13:29:24 going to check it again Jun 13 13:29:50 ynezz: also when looking at 450 and 450G Jun 13 13:30:03 wouldn't it be safer to put 450G before 450? Jun 13 13:32:06 to avoid accidental matching on later potential changes Jun 13 13:33:45 ynezz: does moving the rb* check in its own function with a second switch really increase execution speed? Jun 13 13:35:29 I'm not going to measure it, but it should Jun 13 13:36:16 chunkeey even analyzed back to the busybox pattern matching Jun 13 13:36:24 (if I remember it correctly) Jun 13 13:37:28 xback: makes me wonder if that PR was ever actually run tested Jun 13 13:54:55 xback: I've created simple testing script http://paste.ubuntu.com/p/DJjV45Y4xG/ Jun 13 13:55:10 so the order doesnt matter Jun 13 13:55:22 but this is bash, so who knows how it looks like on ash Jun 13 14:00:58 ynezz: the order will indeed work as it's currently, but it's mere preventing stuff later on Jun 13 14:02:05 like for example? Jun 13 14:03:17 as an example, a new board comes out: 450A Jun 13 14:03:41 and someone thinks .. lets just add a * after "450" to cover all those boards .. Jun 13 14:04:09 but this is nonsense isn't it ? Jun 13 14:04:27 it feels less error prone Jun 13 14:05:05 that mistake sounds rather obvious on review Jun 13 14:05:15 fully agree it's a minor detail :) Jun 13 14:05:50 also it would break excpected alphabetical order Jun 13 14:06:34 thats true .. Jun 13 14:06:53 skip my comment then :) Jun 13 14:09:33 let's assume contributors to be smart enough to not make this type of mistake ;) (and if they do, their contribution will have enough other issues to serve as red flag for a thorough review) Jun 13 14:12:12 hmm somebody could check that "unbound-daemon" pull "libunbound-heavy" as a dependency? :\ Jun 13 14:18:16 xback: http://paste.ubuntu.com/p/4XwywDqN2G/ Jun 13 14:18:50 xback: https://git.openwrt.org/4a66fd7a4fcf5785e176e2324e85b7e4d009f70f Jun 13 14:21:22 sorry, wrong pastebin http://paste.ubuntu.com/p/4WjknCmMhT/ Jun 13 14:22:17 left is the input and right is the output Jun 13 14:46:01 heh Jun 13 14:53:32 jow: could you elaborate why getver.sh doesn't simply output a regular commit hash? Jun 13 14:54:52 jow also regarding the opkg license patch, you mentioned to add a PFM ignore to specific functions which don't need the license, could you please advise me which ones? Jun 13 14:55:17 I'd say I't also usefull for `opkg info vim` Jun 13 15:11:32 aparcar[m]: to be able to tell instantly which version is older when comparing two version strings Jun 13 15:14:33 KanjiMonster: nice, thanks! Jun 13 15:27:19 * ldir arrives home - only Rich to go :-) Jun 13 15:45:24 ldir: hope you had a good trip! Jun 13 15:45:53 ynezz: regarding the append-metadata and check-size function, metadata comes last right? Jun 13 15:50:38 aparcar[m]: yes, basically apply PFM_LICENSE to all the opkg commands that already set PFM_SOURCE Jun 13 15:51:24 aparcar[m]: append-metadata goes before check-size if sysupgrade image can be used in OEM firmware and/or bootloader because they don't strip metadata off before flashing. Jun 13 15:51:56 jow: that's what I needed to know, thanks. Will send a v2 soonish Jun 13 15:52:49 gch981213: thanks, currently this seems mixed http://sprunge.us/VGGaWh Jun 13 15:58:50 aparcar[m]: Most sysupgrade images for routers with nor flash can be used in bootloaders. As for sysupgrade-tar, in order to use this image we have to extract kernel/rootfs from it and the metadata won't get into flash. Jun 13 16:01:23 in case someone can test and apply the latest ct firmware, per my mail to openwrt mailing list, I'd appreciate it and welcome feedback. Jun 13 16:01:24 aparcar[m]: Oops... For sysupgrade-tar, check-size applies to the rootfs image file inside tarball. Jun 13 16:13:57 how can I force reload all targets information via make? Jun 13 16:14:04 withouth actually touching a file Jun 13 16:16:12 greearb_: not sure I can do it, but I've seen you're email and make sure it gets done - this reply to indicate you're not a lone voice crying out into a wilderness :-) Jun 13 16:18:41 ldir, that is much appreciated :) Jun 13 16:40:04 One of the last three commits to 19.07 broke marvel Jun 13 16:45:54 xback: when backporting commits from master, you can use git cherry-pick -x to automatically add a reference to the original commit to the commit message - makes it easier tell apart backports from fixes only needed for that branch Jun 13 16:46:37 Quazil: it's a known issue. Can You test this patch: https://paste.debian.net/1087758 and report back if there is no issue with network? Jun 13 16:47:44 `cherry-pick -x` Thanks KanjiMonster! Jun 13 16:48:01 greearb_: I've been testing the firmware from 20190528 (which appears to be the same as the 009 one you just posted) and it has worked without problems. I see you have pushed a couple of commits to the driver recently and I will put those in my build now. Jun 13 16:48:05 greearb_: done the work, have a commit - just doing a test build, then will push. Jun 13 16:49:12 greearb_: to clarify, have done the firmware bumps - not sure what is done driver wise Jun 13 16:49:31 mamarley: do you know what is done to bump the driver? Jun 13 16:50:04 ldir: I know how to do it well enough to compile it for my own use, but not for actually pushing it to git. Jun 13 16:50:38 ok - I'll look at the other driver bumps to see what/if/how :-) Jun 13 16:50:51 thanks Jun 13 17:02:45 jow: so PFM_LICENSE shouldn't be at status, info, install and upgrade right? Jun 13 17:03:01 greearb_: Did you intend to delete the 5.1 driver entirely? Jun 13 17:03:55 yes, moved it to 5.2 Jun 13 17:04:20 aparcar[m]: sounds about right Jun 13 17:04:37 I don't plan on doing any real dev on 5.1 at this point, so it would have just rotted I fear Jun 13 17:05:53 jow: do you mind me cleaning up that list in another PR? Jun 13 17:06:11 aparcar[m]: no Jun 13 17:12:55 Is there a reason why //base-files/ doesn't seem to be used for "crowded" targets like ath79? Jun 13 17:13:23 (past the work required to split out already-existing code) Jun 13 17:14:52 Supported in package/base-files/Makefile:124 define Package/base-files/install and confirmed to work as expected Jun 13 17:26:32 ynezz: want me to do some compile-tests for the targets you switched to 4.19 in your staging tree ? Jun 13 17:28:12 oh you're from Ostrava. I'll ping you next time I'm going there, we can have a beer :) Jun 13 17:32:42 anyone know if current openwrt works on plume 'superpods' with 9984 radio in them? Jun 13 18:42:37 tmn505_: I can and will test it tomorrow ... IT guy didn't order Internet in time for move to new building so we're figuring out how we're going to get our VoIP phones to work. Jun 13 19:01:10 I'd like some thoughts here https://github.com/openwrt/openwrt/pull/2124 "split DEVICE_TITLE in multiple variables" Jun 13 19:24:46 stintel: https://pad.riseup.net/p/openwrt-4.19 Jun 13 19:26:37 so either you can build test some missing combinations (don't know if it's necessary) or fix some broken target Jun 13 19:27:54 and next time you're around here, just drop me an email and we can erase some brain cells, yeah Jun 13 19:30:46 just please mark it, that you're (or someone else is) working on that target/fix so we don't duplicate the work :) Jun 13 20:19:52 cotequeiroz: ping Jun 13 20:41:18 mangix: pong Jun 13 20:47:14 Is there a way to trigger a script when issuing a reboot? Jun 13 21:10:09 mangix: I'm leaving now, and should be back tomorow at 11h00 UTC, if you need me. Jun 13 21:35:41 dissent1: replace /sbin/reboot with your script Jun 13 22:05:27 ynezz: ah, everything has been tested already I see Jun 13 22:05:29 Quazil: is there a less invasive way? Jun 13 22:06:24 ynezz: I'll check sunxi/cortexa53 - I have that toolchain from another target Jun 13 22:26:09 ynezz: https://git.openwrt.org/09c6885ce789c57be6c2fa6a3e354d4329945714 - I would put this before your 4.19 bump Jun 13 22:26:31 or I can just push it to master after testing so you can just rebase Jun 13 22:29:21 hmm, now I suddenly hit BLK_CGROUP_IOLATENCY Jun 13 22:34:17 That's because it IOLATENCY defaults to 32767 seconds and it just triggered Jun 13 22:34:36 stintel: it's fixed in my tree already Jun 13 22:34:47 I mean that blk iolatency Jun 13 22:34:58 thanks for taking care of that sunxi target Jun 13 22:35:14 yea, just push it to master Jun 13 22:35:26 I'll rebase and retest later Jun 13 22:36:13 ah Jun 13 22:36:36 right. I was testing with master + my change for sunxi and CONFIG_TESTING_KERNEL=y Jun 13 22:37:31 ynezz: what about this instead: https://gist.github.com/f33d8822f110751bc9b353ee8c0c9300 ? Jun 13 22:37:45 (untested) Jun 13 22:38:36 and you're welcome, thanks for taking care of the 4.19 bumps :) Jun 13 22:40:39 sure, if this is prefered way of handling it then please do it Jun 13 22:40:49 well I'm honestly not sure :) Jun 13 22:43:11 I'm buildtesting sunxi on master + https://git.openwrt.org/09c6885ce789c57be6c2fa6a3e354d4329945714 + https://gist.github.com/f33d8822f110751bc9b353ee8c0c9300 with CONFIG_TESTING_KERNEL=y - if that builds I'll just push the missing arm64 erratum symbol Jun 13 22:43:33 leave the other one up to you - maybe discuss it tomorrow with other people Jun 13 22:44:52 pf_ring seems to not build on 4.19 - that's a kmod from packages feed so shouldn't fail the phase1 builds Jun 13 22:44:59 or should it Jun 13 22:52:52 stintel: could you elaborate on your testing? We could just setup an CI which builds staging dirs to avoid manual work Jun 13 22:53:08 s/We/I/ Jun 13 22:55:32 aparcar[m]: it's basicly: echo "CONFIG_TARGET_$target=y" > .config; echo "CONFIG_ALL_KMODS=y" >> .config; make oldconfig and then https://git.openwrt.org/?p=buildbot.git;a=blob;f=phase1/master.cfg;h=f5068675bafc9e6485f65774f97795da1f964e96;hb=HEAD#l435 Jun 13 22:55:44 actually, just look at that git link Jun 13 22:56:00 that's what the buildbots do Jun 13 22:56:31 I've been testing a CI/CD pipeline with OVH's CDS but the big issue with that it doesn't support plain git repos :( Jun 13 22:58:25 otherwise quite nice - I've managed to setup auto-build from openwrt master (from github), with a diffconfig downloaded from github gist for rpi0w, then does all those build steps from buildbot phase1, finally scp's the image to my testing rpi0w and runs sysupgrade, and if that succeeds also scp/sysupgrade no another rpi0w running in production Jun 13 22:59:03 rpi0w? Jun 13 22:59:09 Raspberry Pi Zero W Jun 13 22:59:54 thanks Jun 13 23:00:02 yw - hope it helps ;) Jun 13 23:00:24 the script looks somewhat complex, is the config modification already enough for basic testing? Jun 13 23:00:41 A ci doing that would be quite easy to implement Jun 13 23:00:51 sure, those few commands should give a config with all kmods enabled and then you could just run make Jun 13 23:01:04 anyone know the difference between HOST and HOSTPKG? Jun 13 23:01:10 but splitting it in these steps makes it much easier to pinpoint where exactly the failure happened Jun 13 23:01:24 how do I compile only kernel(mods)? Jun 13 23:01:49 make target/compile Jun 13 23:02:32 afaik Jun 13 23:03:23 target/linux/compile for building the modules themselves, target/linux/install for kernel (+ images, no way to get one without the other); package/linux/compile for wrapping the modules into ipks Jun 13 23:03:39 KanjiMonster: thanks Jun 13 23:05:14 I was just being lazy and getting it from the buildbot p1 config instead of actually thinking Jun 13 23:07:18 I'll look into it Jun 13 23:07:41 and where are the kernel modules stored? So I can make a git diff on that folder to see if modules changed, and only run those tests in case Jun 13 23:07:43 stintel: still undecided if your new cgroups symbol should depend on !4.9 !4.14 Jun 13 23:09:49 aparcar[m]: the .ko files are in build_dir/target-*/linux-*/linux-*///.ko (whereever they get build), the packaged kmod-*.ipks will be in bin/targets///packages/ Jun 13 23:10:29 Package kmod-openvswitch is missing dependencies for the following libraries: Jun 13 23:10:29 nf_conncount.ko Jun 13 23:10:31 nsh.ko Jun 13 23:10:32 meh Jun 13 23:12:02 and: .config:4131:warning: symbol value 'm' invalid for NF_NAT_REDIRECT Jun 13 23:12:46 KanjiMonster: could go with https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=158dbfead01a4c58e939eda896406b655163ecda too - not sure what's best here Jun 13 23:13:38 me neither Jun 13 23:13:58 anyway, openvswitch is in packages feed, the packages folks can look into it after the 4.19 bump is pushed Jun 13 23:14:11 stintel: nice, thank you. I'll try to set something up next week Jun 13 23:14:21 stintel: a few netfilter extensions went from modules to build options for the generic netfilter module or something like that Jun 13 23:16:32 stintel: https://github.com/torvalds/linux/commit/1ac89d20150e377b74d2ef23f56db0f08088426c Jun 13 23:17:11 aparcar[m]: I don't see your fix in PR2124 Jun 13 23:18:00 aparcar[m]: ah, just the TP-Link name, ok Jun 13 23:18:46 kmod-wifidog-ng also fails to build against 4.19 Jun 13 23:22:34 pepe2k: I'm trying to get the strip work Jun 13 23:22:55 but maybe because it's $$ the strip is performed before variable insertion Jun 13 23:23:14 and therefore not working. you got a better idea Jun 13 23:25:26 pepe2k: would be very helpful if you got an idea, I'm stucking Jun 13 23:33:35 anyone know the difference between STAGING_DIR_HOST and STAGING_DIR_HOSTPKG? I can't tell when the build system decides to use which Jun 13 23:35:08 pepe2k: okay solved, makefile is so much fun: https://github.com/openwrt/openwrt/compare/27f2232a997195c8336f7b927ec79b85a5391d97..c4f7fe415b1ceecc71534d97a00ec97b2fcb54af Jun 13 23:35:41 aparcar[m]: one more thing, I don't think 'Device' is correct place for that Jun 13 23:36:38 maybe 'Device/Init' Jun 13 23:41:18 pepe2k: that won't work as device title has to be initialized first Jun 13 23:41:26 or "given a value" Jun 13 23:44:49 aparcar[m]: Device/Check/... ? Jun 13 23:47:50 done. I'll go to sleep now Jun 13 23:48:10 looks good to me, would be nice to get this for all targets soon Jun 13 23:48:55 don't forget about 'DEVICE_DESCRIPTION' in Device/InitProfile Jun 13 23:49:53 but that should expand when used, better to check Jun 13 23:49:54 aparcar: PR#2124: nice idea. This will add more order to device's title Jun 13 23:53:12 aparcar: I do have a question. Usually all devices / boards have a revision. Should we fill that field for all devices or only for the ones that have multiple revisions supported on OpenWRT? Jun 13 23:54:18 luaraneda: in general we include version/revision only if it's clearly marked on device/box by the vendor Jun 13 23:57:09 pepe2k: DEVICE_DESCRIPTION should work also, but where can I find the description? Jun 13 23:57:30 oh, pressing "?" Jun 13 23:57:35 luaraneda: so even if only one revision gets support but it's marked on device, it's better to include it, otherwise we might get MODEL A, MODEL A v2 Jun 13 23:57:57 pepe2k: okay, DEVICE_DESCRIPTION works as well from what I can tell Jun 14 00:00:06 aparcar[m]: be careful with testing such changes on a single device... I've seen issues like device using variable defined in previous step/device definition :) Jun 14 00:00:49 there was something to dump all info, DUMP=1? Jun 14 00:00:53 That's why I'm reseting the data on every Init, I fogot it it first so everything suddenly had v3 attached Jun 14 00:01:50 pepe2k: doesn't work here, http://sprunge.us/xj3hbe Jun 14 00:02:14 argh. 3AM. nn folks :) Jun 14 00:02:31 2am here, np Jun 14 00:02:39 stintel: gnite :) Jun 14 00:09:50 pepe2k: thanks Jun 14 00:10:37 aparcar[m]: check tmp/.targetinfo Jun 14 00:10:47 ynezz: fyi pushed the sunxi fix Jun 14 00:11:54 instead of actually going to bed I'm doing `pflash -E -p habanero.pnor` in my Power8 box' BMC :p Jun 14 00:12:36 yolo Jun 14 00:12:39 @aparcar[m]: and also tmp/info/targetinfo-ath79 Jun 14 00:14:10 will do tomorrow Jun 14 00:14:11 cu Jun 14 00:14:19 bye **** ENDING LOGGING AT Fri Jun 14 02:59:58 2019