**** BEGIN LOGGING AT Sat Nov 16 02:59:57 2019 Nov 16 04:55:09 build #37 of ramips/rt3883 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/ramips%2Frt3883/builds/37 Nov 16 07:28:38 aparcar[m]: FYI, just stumbled upon https://github.com/patchew-project/patchew Nov 16 07:29:36 lynxis: you had access to our coverity login right ? Nov 16 07:29:43 + morning Nov 16 07:30:16 morgen Nov 16 07:30:23 I can see lynxis as admin Nov 16 07:31:02 https://scan.coverity.com/projects/openwrt?tab=members Nov 16 07:35:10 lynxis: can i get access ? Nov 16 07:35:50 blogic@openwrt.org is there as admin Nov 16 07:36:09 ah great Nov 16 07:36:17 jow, thank you, that got it to compile Nov 16 07:36:17 that is why i can't reset my passwd :-D Nov 16 07:36:34 ynezz: thanks Nov 16 07:36:52 blogic: just create a new user and I can add you Nov 16 07:37:14 everyone with commit access has admin on covertiy Nov 16 07:37:49 created a new account Nov 16 07:38:11 sent a request Nov 16 07:38:32 Project role for user John Crispin approved. Nov 16 07:40:12 great ! Nov 16 08:00:07 that coverity UX is the worst I've ever experienced Nov 16 08:02:36 I'm not even able to get a list of issues for uci for example, meh Nov 16 08:02:51 probably need some training Nov 16 08:48:32 ynezz: takes getting used to Nov 16 08:48:41 I just fixed a pile of fstools reports Nov 16 08:48:45 :-) Nov 16 09:25:51 blogic: you added a stray + in your boot fix commit ;) -> https://github.com/openwrt/openwrt/blob/master/target/linux/mediatek/mt7629/config-4.19#L238 Nov 16 09:27:28 does that mean it's an extra good line? Nov 16 09:54:16 lynxis has a Jenkins running which uploads its results each Sunday to coverity Nov 16 10:11:01 in an effort to selectively enable JIT-support for pcre i made some changes to its Makefile: https://pastebin.com/5J8dwtJm Nov 16 10:11:46 can someone with more experience have a look at it, specifically lines 54-59 and 67? Nov 16 10:12:35 please :) Nov 16 11:07:27 gladiac1337: well, it's better to pastebin the output of git diff or git format-patch Nov 16 11:09:22 ynezz: https://github.com/gladiac1337/openwrt-packages/commit/885ba15c4f31be2ddaf8d5b82aa6702613c06952 Nov 16 11:10:01 ynezz: agreed Nov 16 11:10:41 gladiac1337: you're missing answer to Why? do you need these changes question in your commit message Nov 16 11:11:05 You are right, I forgot to mention the 10x speed upgrade by using jit Nov 16 11:13:44 speed is just one variable, then there is flash size, RAM usage etc. Nov 16 11:14:13 but I assume this is not an issue on x86/ipq806x Nov 16 11:15:59 maybe turning this into config option and make it opt-in would make sense as well, if its unknown how much this JIT is stable and backward compatible Nov 16 11:16:27 because turning this on by default might introduce some regression in some cases Nov 16 11:16:48 (but I don't know anything about this topics, just general ideas) Nov 16 11:19:56 I just redid the commit message: https://github.com/gladiac1337/openwrt-packages/commit/876c7796b48ce102fe8b38f333d0d6a4a1ad6695 Nov 16 11:22:07 The only penalty i am aware of is that it breaks pcre's operation if you enable it on platforms that are not supported. If i remember correctly the build fails because JIT uses asm which does not exist/work for unsupported targets. But I have to verify on that. Nov 16 11:22:29 However, that is why I conservatively enable JIT only on targets that I can test for. Nov 16 11:23:28 Making it a config option could be an even better solution though... And just enabling it by-default on platforms I can test. Nov 16 12:36:01 I just made a commit which introduces JIT via a config-option: https://github.com/gladiac1337/openwrt-packages/commit/00d1ec7a132656ab992f32d3b3bbea4cbf3e3d44 Nov 16 12:36:14 I am not sure now what's the better approach Nov 16 13:24:07 Hello Nov 16 13:24:10 Good day! I am looking for a developer who can adapt LEDE firmware for a number of devices that are not currently supported by it. Device list: TP-Link TD-W8901N, TD-W8961N, TD-W8960N, TD-W8968, TD-W8920G, Tenda D301 modem, Zyxel P600 series modem. Each device needs full support so that you canUsing the local assembly system to create the necessary Nov 16 13:24:11 firmware image. This work will be adequately paid.Are there any people here who could do this. Nov 16 13:31:22 not-alone: are these devices based on broadcom DSL SoCs? Nov 16 13:36:48 the first one (a v1 at least) looks like ralink, but not a supported one http://en.techinfodepot.shoutwiki.com/wiki/TP-LINK_TD-W8901N_v1 Nov 16 13:37:20 Unfortunatly, i dont know Nov 16 13:39:22 TD-W8961N is based on Trend Chip TC3162U-LQ128G Nov 16 13:40:47 nope, that information is for TD-W8951ND that is not in our list Nov 16 13:41:14 I just looked at this one: https://oldwiki.archive.openwrt.org/toh/tp-link/td-w8960n Nov 16 13:42:05 not-alone: a lot of those have multiple revisions, and SoCs can change between those. the W8961N is ralink as well it seems (again multiple revisions) Nov 16 13:42:11 The DSL of the broadcom SoCs is not supported in OpenWrt, here you have to talk with Broadcom first to make them change their license if you buy enought of these these chips could be possible (some millions) Nov 16 13:42:55 understand... Nov 16 13:43:26 32 MB ram and 4 MB flash is also not supported by OpenWrt any more Nov 16 13:44:53 its no good Nov 16 13:45:06 thank u for answer Nov 16 13:46:21 if the SoC and the other chips are already supported it is not so hard to add support for a new device, but if support for a new SoC or wifi chip has to be added it is a huge task Nov 16 13:49:39 thank u for answer Nov 16 13:49:41 after what you said, I'm starting to think that it’s easier to purchase several thousand devices that are obviously supported by OPENWRT instead of this zoo of outdated modems. After that, collect custom firmware for them and enjoy life. Nov 16 14:05:44 not-alone: DSL works in OpenWrt only for some Intel/Lantiq SoCs and some very old TI SoCs Nov 16 14:07:42 With any xDSL (or almost any other connection than eth) I've long time ago just accepted the fate that having separate modem with passthrough capabilities and then the openwrt device for the taskis best scenario in general Nov 16 15:18:21 need get some qos finally, so sqm is the one preferred to qos-scripts, is there a way "assign" a certain bandwidth to each wifi sta(CBR), the reason is that I need benchmark a wifi app's behavior under different bandwidth scenarios Nov 16 15:19:05 did some basic reading and I saw nowhere sqm(or qos-scripts) can restrict wifi-sta's bandwidth Nov 16 15:36:00 jow: Had more of a think about that dhcp/v6 release/norelease inconsistency and decided in the end that dhcpv6's norelease=1 made slightly more sense - don't know what you think of https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=1baff937894f7901a94cc92df2a1dbc4338e68f4 Nov 16 15:37:35 not sure where the migration script should go Nov 16 15:46:33 ldir: you can do the commit unconditionally, uci won't rewrite unchanged configs. and maybe norelease=$((!$release)) ? norelease and release are so similar I had to re-read the line a few times until I understood what it does. And yes, uci-defaults is the right place Nov 16 15:54:15 KanjiMonster: good ideas - ok if uci-defaults is the correct place, should the migrate file be a separate commit to 'base-files' package? Nov 16 15:54:51 hi :) Nov 16 15:57:32 I have been playing around with the openwrt linux kernel and I saw that CONFIG_HIGH_RES_TIMERS is not enabled across all platforms. Unfortunately it is not possible to put it into an external kmod... What do you think are the chances of officially building with high res timers? Nov 16 15:58:52 I know it is probably dependent on whether hardware needs them or not. But this also leads to a kind of inconsistent set of SYSCALLs across openwrt :/ Nov 16 15:59:14 e.g. nanosleep is probaly not available Nov 16 16:18:41 spongy: you should mesure how much bigger a kernel gets when this is activated Nov 16 16:18:56 probably check this on one of the mips paltforms as they have the most problems with size Nov 16 16:19:18 when you have these information just send a patch Nov 16 16:24:02 Hauke: ok, i'll check that out soon :) I just wonder whether there are other arguments except for size :/ Nov 16 17:27:26 am I the only one having problems compiling 19.07 branch? I tried fresh clone and still getting recursive dependency detected errors from kconfig. lantiq_xrx200 target Nov 16 17:33:41 Weasel_: that shouldn't prevent compilation Nov 16 17:41:46 Weasel_: nfs kernel server? Nov 16 17:41:52 and like jow said ^^ Nov 16 17:46:41 Borromini: yes. somehow kernel config fails and starts asking questions about how to configure, starting with "VGA text console (VGA_CONSOLE) [Y/n/?] (NEW)" Nov 16 17:47:44 scripts/kconfig/conf --silentoldconfig Kconfig Nov 16 17:47:44 net/sched/Kconfig:44: warning: menuconfig statement without prompt Nov 16 17:48:04 hmm i am not seeing that issue (just the warnings thrown about recursive dependencies) Nov 16 17:48:08 after that, * Restart config Nov 16 18:56:14 If I'm going to disable a device image by default because its too big with the release pacakge set (luci et al) should I first disable it in master and cherry pick to 19.07 or disable in 19.07 only ? Nov 16 18:58:21 jow, what do you mean? What device? Nov 16 18:59:09 I mean http://sprunge.us/OFafld Nov 16 18:59:43 that commit causes it to not get built by defualt anymore but users doing custom builds or using the IB can still build an image for it Nov 16 19:00:13 question is whether to introduce it via the master branch or for the release branch only and keep it building in master snapshot Nov 16 19:00:18 its a process question more or less Nov 16 19:06:45 jow: as the snapshots do not have luci I would only deactivate it in 19.07 Nov 16 19:07:13 I didn't know of this DEFAULT option, I often deactivated them by removing the TARGET_DEVICE Nov 16 19:14:54 ldir: one commit, to keep it atomic Nov 16 19:15:10 Hauke: it's relatively new, basically mirrors what we have for packages Nov 16 19:15:42 Hauke: yeah, KanjiMonster introduced it recently and its a perfect way to "soft disable" devices Nov 16 19:16:53 Hauke: ok so 19.07 only, similar to how we disable targets in the release branch only Nov 16 19:18:46 jow, I do not like this idea at all Nov 16 19:19:24 Why not to fix it? Nov 16 19:20:09 Necrosporus: fix how? By magically making software smaller? We've been trying that for years, doesn't work Nov 16 19:20:20 jow: you could do some elaborate stuff like "DEFAULT:= y if TARGET_ALL_PROFILES && !PACKAGE_luci", but just n is also fine Nov 16 19:20:25 By removing one or two packages? Nov 16 19:20:44 thats not how releases work Nov 16 19:20:49 at least not for openwrt Nov 16 19:21:12 jow, how about to move the firmware partition one erase block down? Nov 16 19:21:36 no idea how to do that Nov 16 19:21:42 There is one unused erase block in devconf partition Nov 16 19:21:53 it would be up to the target maintainer to do that Nov 16 19:22:09 and even then it'll likely be broken again with the next release Nov 16 19:22:15 Is it impossible to remove something unnecessary from this device? Nov 16 19:22:23 pppoe for example Nov 16 19:22:51 we don't arbitrarily alter the package selections for single devices Nov 16 19:23:07 all devices get the same set of packages Nov 16 19:31:50 jow: btw disregard my suggestion, doesn't work that way Nov 16 19:43:59 KanjiMonster: thank you Nov 16 19:45:42 Is chopping one's head off with an ax a good cure for headache? Nov 16 19:47:51 it's a permanent solution for a temporary problem ;) Nov 16 19:51:10 jow, I highly suspect that the problem with no enough space for config files is hitting a lot if not all of 4M flash devices Nov 16 19:51:14 not just this one Nov 16 19:52:23 Why not to fiddle some config options of the kernels to remove something unused? Nov 16 19:52:36 For entire platform perhaps Nov 16 20:09:58 Necrosporus: there are no magic unused features left to disable to make it fit, this is the death of a thousand cuts - kernel code is growing larger, userspace code/libraries are growing larger Nov 16 20:10:32 feel free to send patches if you find something though Nov 16 20:11:01 KanjiMonster, LuCI ? Nov 16 20:11:27 again, all release images come with the same feature set Nov 16 20:11:31 not some with and some without luci Nov 16 20:11:35 or some with and some wirthout pppoe Nov 16 20:11:45 if you want a random samll image, use a snapshot Nov 16 20:11:56 or download the imagebuilder and pack yourself an image without luci Nov 16 20:12:12 any deviating package selection per device will introduce *massive* amounts of overhead work Nov 16 20:13:00 this discussion has been made ad nauseum. Eventually all 4MB devices will be unsupported Nov 16 20:13:26 and yeah you can remove the 250KB luci, some future kenrel 5.x will also eat those KBs away and we're having the same discussion again Nov 16 20:13:32 jow, but 19.07 claims to still support 4MB devices. Nov 16 20:13:34 right now it is too late Nov 16 20:13:46 19.07 was there since july Nov 16 20:14:04 rc1 is there now and we will disable known broken images Nov 16 20:14:17 final will ship without them Nov 16 20:14:45 Necrosporus: 19.07 is the last release that may be usable on some subset of 4MB devices Nov 16 20:14:52 it does not claim to support all 4MB devices Nov 16 20:34:49 I isolated my 19.07 compile problem to CONFIG_DISPLAY_SUPPORT=y, if that is set compile fails Nov 16 20:41:44 I'd like to have my wlan0 (2ghz) users and wlan1(5ghz) users to have different default gw uplinks on the router. I was thinking of setting different fwmark on packets incoming on wlan0 and wlan1 then route depending on the fwmark. Is this a good way or something else that anyone can think of? Nov 16 20:42:05 Also having difficulties simply marking my wlan0 packets differently from wlan1 - any tips? Nov 16 20:42:52 4M devices should have died years ago, I made some of the last desperate fiddles a while ago.. Nov 16 20:59:28 Monkeh, they are routers. They can route networks packets. Actually routers with just 2M flash and 16M ram exist Nov 16 20:59:39 Some of them are even still sold new Nov 16 21:00:59 That's very nice, you try and squeeze a practical OS with modern code in there and maintain it Nov 16 21:02:12 How the vendors do it? Nov 16 21:02:46 Badly, with no concern for security or maintainability Nov 16 21:05:38 Exactly that, lacking.. even the more reputable doesn't really take too much care... also it is somewhat easy to purpose build something for smaller device, which works only there, if even Nov 16 21:06:21 Not to say plenty flash or ram alone makes winner, but that is good start Nov 16 21:07:22 Expensive makers often have, say, 128megabytes of flash, with dual.images and whatnot.. Nov 16 21:09:27 Ofcourse, bigger code there doesn't make ultimate device.. but at least they make means to be able to... openwrt otherhand tries to keep things efficient... which means it tries to do stuff as small as possible, but still in itself it isn't the main goal I'd say (while I'm no owrt dev) Nov 16 21:10:07 jow: is there a schedule for rc2? Nov 16 21:32:10 does NPX / Freescale make and design their own boards or does someone else? Nov 16 21:34:38 is it possible to change device tree without rebuilding openwrt image? Nov 16 21:34:49 I want to correct just one digit Nov 16 21:36:56 Necrosporus: device tree needs to be compiled, so no Nov 16 21:37:55 but where is it physically? if it's not inside LZMA area of the kernel it can be still edited with hex edit if you figure out byte translation Nov 16 21:38:10 Alright, I change question. I want to override partition table Nov 16 21:38:24 Necrosporus: you also need to recalculate the checksum if you edit it Nov 16 21:39:09 When it was in command line I was probably able to use u-boot environment or somethingh Nov 16 21:39:27 Now it's in device tree. Can it be overriden somehow? Nov 16 21:45:57 Necrosporus: see https://forum.openwrt.org/t/tutorial-build-custom-netgear-r7800-firmware-for-a-larger-flash-size-root-space/5989/12 Nov 16 21:46:17 not sure if that answers your question... but it might get you going Nov 16 21:49:29 it likely will be easier to edit dts and recompile tho Nov 16 21:50:47 Probably. thanks anyway. **** ENDING LOGGING AT Sun Nov 17 02:59:57 2019