**** BEGIN LOGGING AT Wed Apr 17 02:59:57 2019 Apr 17 09:19:42 hello Apr 17 09:20:26 probably me being stupid, but when doing "make package/system/fstools/clean" then "make package/system/fstools/install", I see the new binaries installed in ./staging_dir/target-arm_cortex-a7_uClibc-1.0.14_eabi/root-/ Apr 17 09:20:55 but the new binaries are not installed in ./build_dir/target-arm_cortex-a7_uClibc-1.0.14_eabi/root- which I guess is what is used to produce the final rootfs Apr 17 09:31:05 what about make package/fstools/{clean,compile} ? Apr 17 09:31:37 Hello and good morning / day to all of you! Or night if the timezone is that . :D Apr 17 09:32:04 May I ask you what's the proper way to set MTU / metric on a protocol handler ? Apr 17 09:32:13 I could find only examples relating to tunnels Apr 17 09:32:32 in e.g.: vti.sh Apr 17 09:32:48 karlp: well, package/system/fstools/{clean,compile,install} are doing what they should, except installing to build_dir/.../rootfs-something Apr 17 09:33:13 or may I use directly "ip link ..." ? Apr 17 09:35:47 kos_tom: my buildir/target/fstools-ver/ipkg-install has the new version, and my staging dir has the new version Apr 17 09:36:00 I'd almost say the builddir/target/root/ version is detritus that shouldn't exist? Apr 17 09:36:33 thermeote gdb scripts use the staging dir, not the build dir Apr 17 09:41:06 to be honest, this is with some old vendor-modified OpenWRT, so perhaps I should first check the behavior with a recent upstream OpenWRT Apr 17 09:42:55 well, I was just doing the same thing with about a week ago openwrt. Apr 17 09:43:11 and i see the same behaviour as you, but I think there's no problem. Apr 17 09:43:24 or at least, the stale version in builddirr/root is a red herring I think. Apr 17 09:43:35 just don't use builddir/root, use staging-dir/root Apr 17 10:13:33 any help would be greatly apreciated; Apr 17 10:13:56 kos_tom: the root in build_dir is populated during the global package install / image generation phase Apr 17 10:14:07 kos_tom: individual package build targets will not touch it Apr 17 10:40:57 jow: hello! Apr 17 11:17:37 jow: so if staging root gets updated, what is builddir root for? Apr 17 11:24:33 karlp: for assembling the image Apr 17 11:24:44 mklibs, opkg metadata stripping, overlay files etc. Apr 17 11:39:03 so when I'm using files from staging root, they're not stripped, and you have to do a full image build to get that all? Apr 17 11:39:22 jow: ok, thanks. What is the right make target to invoke to re-populate this root in build_dir ? Apr 17 11:44:08 kos_tom: make target/linux/install Apr 17 11:48:02 karlp: staging_dir/target-*/root-*/ is more or less the union of all "define Package/install" targets, the intermediate pkg-install directories copied together Apr 17 11:48:29 jow: ok, thanks for the explanation, I'll try that Apr 17 11:50:09 karlp: it appears to serve as reference for mklibs at least and the build system code uses the ko files staged in there to build kernel symtab files Apr 17 11:50:29 karlp: apart from that it is surprisingly unused, looks like some legacy build system artifact that was never propably factored out Apr 17 11:52:09 for reference, compare `grep -r STAGING_DIR_ROOT rules.mk include/ package/Makefile` (the staging root-*) with `grep -r TARGET_DIR rules.mk include/ package/Makefile` (the build dir root-*) Apr 17 11:52:34 the former is basically only used by this symtab script and mklibs (which in turn is also quite broken as far as I know) Apr 17 11:53:12 anything involving rootfs generation, opkg install etc. uses TARGET_DIR (aka. build_dir/target-*/root-*) Apr 17 11:54:25 and the remote-gdb script.... Apr 17 11:54:39 it uses staging dir root. Apr 17 11:54:50 Ok guys, I may have lost some messages due to issues with my ADSL Apr 17 11:54:52 right, ye Apr 17 11:54:54 or something like that Apr 17 11:55:12 karlp: thats the other use case for staging_dir root-*, it can serve as sysroot for gdb/gcc etc. Apr 17 11:55:36 it's just the stripping in builddir that is the problem there right? Apr 17 11:55:39 jow: hello! May I ask you for help with my proto handler issue? :D Apr 17 11:55:58 jow: I was searching for the proper way to set MTU / metric on a protocol handler, but ... not on a tunnel interface Apr 17 11:56:10 karlp: the other problem is that build_dir root-* only contains binaries that are to be embedded in the image Apr 17 11:56:24 while staging_dir root-* should contain all things built as M Apr 17 11:56:30 ahh, that too. Apr 17 11:56:42 thanks. Apr 17 11:57:15 so scratch my "legacy build system artifact that was never propably factored out" Apr 17 11:57:45 it rather is a directory suitable for gdb and gcc sysroots Apr 17 11:58:12 karlp: maybe my comment is completely wrong but... setting stripping method to NONE? Apr 17 11:59:36 mrkiko: option mtu should work Apr 17 12:00:29 jow: sorry, I was referring to .. .how do I do that inside a protocol handler script Apr 17 12:01:27 you register the mtu option (for /e/c/network) with proto_config_add_int "mtu" Apr 17 12:01:40 jow: and - regarding metric, I was people doing something like "json-add_int ..." but ... it seems to have no impatct for me at the moment; I think I am doing something wrong but... don't understand what, yet Apr 17 12:02:01 ok... great! Apr 17 12:02:06 then you handle it within proto_add_tunnel ... proto_close_tunnel using something like json_add_int mtu "${mtu:-1500}" Apr 17 12:02:31 jow: I am not configuring a tunnel but directly an OS interface Apr 17 12:02:39 you can obtain the $mtu value from user configuration using json_get_var mtu mtu or json_get_vars mtu Apr 17 12:03:51 well then use ip link to apply the configured mtu Apr 17 12:04:16 should I use proto_{add,close}_tunnel even when dealing with an interface (e.g.: exposed by a kernel driver) ? Apr 17 12:04:26 ok Apr 17 12:04:31 jow: I resorted to doing that Apr 17 12:05:11 jow: for the metric - how may I deal with it? Is it ? Should I pass it to proto_add_ipv4_route ? Apr 17 12:06:49 no, proto_{add,close}_tunnel only make sense if you want netifd to spawn a new tunnel interface (ip tunnel add ...) Apr 17 12:08:58 yes, you should send the metric to netifd as part of the route spec Apr 17 12:09:18 jow: thank you very very much for your help Apr 17 12:10:51 or rather I think you simply set it as attribute Apr 17 12:12:14 proto_init_update ...; json_add_int metric 100; ...; proto_send_update Apr 17 12:13:10 you can also use proto_add_dynamic_defaults of netifd-proto.sh which will set the generic defaultroute, peerdns and metric values depending on the value of the variables $defaultroute, $peerdns and $metric respectively Apr 17 12:14:19 so 1) in your proto_YOURPROTO_init_config(), add proto_config_add_defaults Apr 17 12:14:34 this will register the "defaultroute", "peerdns" and "metric" options Apr 17 12:15:19 2) in your proto_YOURPROTO_setup(), add something like local defaultroute peerdns metric; json_get_vars defaultroute peerdns metric Apr 17 12:16:32 3) near the end of your proto_YOURPROTO_setup(), when all other attributes have been handled, call proto_add_dynamic_defaults just prior to proto_send_update Apr 17 12:17:40 netifd will then apply the sent metric (if set) to all ipv4- and ipv6 addresses (subnet routes) as well as routes created as part of the interface setup Apr 17 12:18:43 Great! thank you very very much jow... Apr 17 12:18:57 very elegant and concise Apr 17 12:21:20 wops, I was going to do so; but now I realize i am getting only a single vlaue from config, the one that tells me where I will have to read the "description files2, files generated by my application, retrieved from a modem via ModemManager. and those values will need to be bearer-specific, meaning the user may set a per-bearer metric and so on. So... I will keep this to mind, but I guess I'll have Apr 17 12:21:26 to do so per-bearer Apr 17 12:29:05 ynezz: enjoying yourself ? Apr 17 12:29:34 ynezz: why us a trivial solution if you can use a bloated over engineered subsystem that requires patching every driver on the planet :-) Apr 17 12:31:42 blogic: yeah, linux kernel is special :) Apr 17 12:42:41 BTW is there any way, how could I get an email address of the user from bugs.openwrt.org? I got an ACK for his Tested-by tag, but he didn't provided me with the email... Apr 17 12:43:42 ynezz: aren't you admin? Apr 17 12:44:02 you should be able to find this in the user management Apr 17 12:48:21 jow: can you pls give me direct link to that part of the system (user management) ? Apr 17 12:49:15 and I've probably all the permissions (green ticks) but the `is admin` has the crossed red circle (don't know what does it mean in flyspray context) Apr 17 12:49:58 anyway, would be enough if you could just give me his email on /query here Apr 17 12:50:08 https://bugs.openwrt.org/index.php?do=admin&area=groups Apr 17 12:50:27 you're admin now Apr 17 12:50:43 ok, thanks Apr 17 12:50:48 in this edit user field, you need to pick the user from the dropdown, otherwise it will not work Apr 17 12:51:04 from the autocomplete dropdown that appears after typing that is Apr 17 12:53:18 yeah, got it Apr 17 13:21:53 jow: out of curiosity, I kinda imagined that attributes thing, also because on the netifd code I found something like "if ((cur = tb[DEV_ATTR_MTU]) && blobmsg_get_u32(cur) >= 68) {" in device.c; but the values I specified for static configs, where I did set values with calls to e.g.: proto_add_ipv4_address), did not take effect. So I tought I am missing something. Apr 17 13:26:23 Hi all, Apr 17 13:26:46 I've been executing multiple commands at once using braces for a long time now. E.g. make package/xyz/{clean,compile} Apr 17 13:27:20 I'm just curious what is interperting those braces? Is it bash or the Makefile? As you can imagine it is quite hard too google search for that Apr 17 13:27:24 thanks in advance Apr 17 13:28:03 https://www.gnu.org/software/bash/manual/html_node/Brace-Expansion.html Apr 17 13:28:33 olerem: kudos for your ag71xx effort, I'm just curious what device(s) are you testing it on? Apr 17 13:28:48 Neighbor11111111: bash Apr 17 13:28:55 Neighbor11111111:I don't think it's in posix though, but it's in lots of shells still Apr 17 13:29:33 it's apparently in csh, ksh, zsh though, so ~lots of places. Apr 17 13:47:19 hanks karlp donn_ Apr 17 13:47:57 I thought it was bash so I tried an experiement, the following: "echo {hello, world}" Apr 17 13:48:05 but the output was literally {hello, world} Apr 17 13:48:15 can you let me know the feature of bash exactly and I'l research it Apr 17 13:48:18 please? Apr 17 13:50:43 remove the space Apr 17 13:51:40 or, to be easier to see, try "ls {.,.} vs ls {., .} Apr 17 13:52:05 and I linked the bash manual for this. Apr 17 14:00:47 for procd init scripts, with "reload_config" any tips on how to avoid restarting dependent services more than once? Apr 17 14:01:17 I have a script where "init.d/blah start" checks some config for another service, and does a uci commit && reload_config, to make sure that service picks it up, Apr 17 14:01:26 and "stop" does the same thing. Apr 17 14:01:45 but now I get chained process restarts. Apr 17 14:02:29 it's worked ok so far, but I'm trying to diagnose where it seems to lose one of the uci commits or one of the reloads, Apr 17 16:29:04 So sorry karlp I had to go temporarily Apr 17 16:29:10 thanks for the link and the explanation much appreciated Apr 17 17:27:15 the prpl proposal is just because they're too lazy to upstream patches to gcc right? or am I misunderstanding it? Apr 17 18:10:49 well upstreaming takes a long time, look at ARC for example. Its been two years now I think and its still not complete Apr 17 18:43:58 ynezz: only ar9331 based. other devices will need more work Apr 17 18:52:12 jow: if i'm not too late for th epoint release, I'm going to backport few brcmfmac fixes tomorrow Apr 17 18:52:24 karlp: there are differnt parties involved some chip vendors have their own patched toolchain and their users want to use them with OpenWrt Apr 17 18:52:26 if you can wait with tagging for 24 h, that would be great Apr 17 18:52:31 just came back from short holidays Apr 17 18:53:16 and you probably only get support if you use the vendor toolchain Apr 17 18:55:22 Intel uses the normal OpenWrt toolchain for the teclo and retail products Apr 17 18:57:53 well, I quite don't get this special handling, couldn't they just send this explanation as cover letter in that patch series? Apr 17 19:00:49 rmilecki: yes please, I didn't get around to do much this week, so nothing will happen before after the easter holidays on my side Apr 17 19:02:00 ynezz: this mail is an attempt to bring in features / solutions / technological directions in collaboration with the community. Apr 17 19:03:09 ynezz: it was actually some of us suggesting such an approach to prpl, not dump inadequate code after the fact but try to get feedback, opinions etc. early on and find a way agreeable path forward Apr 17 19:06:47 ok, with this additional context that mail probably makes sense Apr 17 19:09:42 so what they're trying to do exactly? something like (binary only) meta layer we know from OE? Apr 17 19:10:13 (you see, too many questions which could be actually answered with the patchset) Apr 17 19:10:49 ynezz: its an RFC/RFD, no patchset Apr 17 19:11:41 from what I've gathered, they seek a way to plug in external toolchains Apr 17 19:12:00 which makes sense. The ability is there, to some extend in OpenWrt but it is tedious to use Apr 17 19:12:47 for example you need to configure the triplets, the file globs for libc, librt etc. shared objects Apr 17 19:12:58 things like config.site for autoconf Apr 17 19:13:41 from what I've gathered, they envision some kind of system where you have a kind of a toolchain repository where some file/manifest/config/Makefile/whatever describes all the relevant properties Apr 17 19:14:09 similar to how package feeds are collections of Makefiles describing package build recipes Apr 17 19:14:28 whether it makes sense to call such a toolchain repository a "feed" is another matter Apr 17 19:16:57 need to run Apr 17 19:17:07 thanks for explanation Apr 17 19:17:27 hi rmilecki Apr 17 19:17:42 rmilecki: thank you again for the mail where you where explaining me about C masks Apr 17 19:17:47 I apreciate it ... Apr 17 19:18:54 rmilecki: BTW, you where very very right about the unsupported Wi-Fi device on the broadcom SOC I work with.... do you remember? I guess I shouldn't hold my breath on that, still. We will change SOC soon ..... Apr 17 19:19:53 gch981213: no worries about that mib fixes, enjoy your Easter holidays :) Apr 17 19:43:56 ynezz: yes the idea is to handle the toolchain somehow like a package in a feed, some chip vendors force you to use a specific (binary) toolchain Apr 17 19:44:47 ynezz: the general idea is to bring more of the private patches vendors add to OpenWrt to make it work for they comercial devices into upstream OpenWrt Apr 17 19:45:02 the toolchain is only one part Apr 17 20:31:05 Hauke: yeah, lets see how this pan outs, more or less I don't get it, why should we even care about their binary needs, don't we get enough binary crap already in the tree? Apr 17 20:34:07 I'm wondering what is it actually bringing to the project in positive sense Apr 17 20:36:26 the negative one is obvious, they're going to solve their maintenance burden and headaches (actually rightful, they deserve it, upstream first or go burn in hell) by moving it on project shoulders Apr 17 20:52:35 ynezz: in a grand scheme of things it might bring more contributions to the project when certain basic needs are covered Apr 17 20:53:16 ynezz: as for the burden; thats exactly why we encouraged them to communicate the plans upfront, so that a plan with minimal impact can be made Apr 17 20:55:36 in the end we're forced to reimplement vendor solutions anyway because they've been built on top of ancient openwrt forks which existed in the first place due to the lack of features such as the external toolchain integration Apr 17 20:55:56 so anything that brings these things closer to current mainline is an improvement Apr 17 20:56:10 thanks guys for all!!!! Have a good night / day! / morning. :D thanks jow, and all Apr 17 20:56:17 sorry, exiting / disconnecting Apr 17 20:56:26 and imho the hardware ecosystem targeted by openwrt is shrinking/cloasing down fast Apr 17 20:57:23 you have proprietary underpowered stuff without drivers on the one side, and big arm stuff on the other side which makes things like openembedded or debian derivates viable Apr 17 20:58:39 so - in my opinion - the only long term solution to keep having access to hardware is to accomodate the needs of vendors to some extend Apr 17 22:03:21 hauke/jow: isn't the pain of maintaining their forks their only incentive to actually get their stuff upstream? if synopsys can't find the time to get their cores supported, that's surely gotta be their problem, and have their customers compalin to them that their tooling sucks. Apr 17 22:06:24 * karlp shrugs. from our point of view as a commercial integrator, we're looking at moving to "bigger arm where debian or ubuntu core snap is viable" but... then we lose all the investment in init scripts and luci apps and have to redo it all. Apr 17 22:07:12 trying to make our own web ui based on networkmanager-cli? man, just stay with openwrt, just run bigger things. Apr 17 22:08:12 I mean, sure whatever, it wouldn't be very intrusive, or "hurt" us, so, sure, why not. Apr 17 22:08:27 just feels like they're leaning on us when they should be leaning on their soc vendors. **** BEGIN LOGGING AT Wed Apr 17 22:48:44 2019 **** ENDING LOGGING AT Thu Apr 18 02:59:57 2019