**** BEGIN LOGGING AT Wed Apr 08 03:00:04 2020 Apr 08 05:42:58 aloha Apr 08 06:00:37 blogic: hi Apr 08 06:00:49 I'm the one on hawaii whats up with you? Apr 08 07:56:41 is this possible to rebuild all device images with device specific rootfs-es using Image Builder? Apr 08 07:56:56 "make image" just uses default target profile for all devices Apr 08 07:57:20 i would like to make use of MULTI_PROFILE Apr 08 07:57:54 let's say I want to repackage 19.07.2 release for all bcm53xx devices with my custom testing script included Apr 08 07:58:36 sth like make image PROFILE=????? FILES=/home/rmilecki/openwrt-test-scripts Apr 08 08:15:02 gch981213: I've got a reply from the original submitter of RBM11G. I've asked him to check whether the ethernet port is actually port0. Apr 08 08:22:33 * ldir mornings Apr 08 08:23:01 ldir: aloha Apr 08 08:24:30 aparcar[m]: indeed! Now why are you in Hawaii? Is that your place of residence? Apr 08 08:25:24 studying Apr 08 08:25:30 the waves? Apr 08 08:25:57 pssst don't tell the teachres Apr 08 08:26:07 o_O Apr 08 08:26:18 *teachers Apr 08 08:26:52 secret is safe with me - mutters something about "lucky bastard" :-) Apr 08 08:37:58 aparcar[m]: you're a student and not full time employed? Apr 08 08:50:28 * russell-- apparently killed his espressobin, possibly the stepdown dc converter (Vout = 0V) Apr 08 09:20:21 Borromini: yes. Who would ever employ me :? Apr 08 09:25:09 russell--: rip Apr 08 09:26:14 russell--: no more coffee for you :-) Apr 08 09:29:23 heh Apr 08 09:31:26 i guess not having a case make it vulnerable to random short-circuits, which seems like the most probably cause Apr 08 09:32:23 * ldir killed an asus netbook yesterday Apr 08 09:34:43 * russell-- recalls paying $49 two years ago Apr 08 09:35:14 even the chip that might be fried is unobtainium Apr 08 09:35:32 not having a case: https://www.linux-ipv6.be/OpenWrt/RSPro/DSCN1116.JPG :D Apr 08 09:39:06 gch981213: the port was indeed port 0, he will send a patch. Apr 08 09:43:57 someone was using the desk it was sitting on, i think some tweezers got pushed underneath the shorted something Apr 08 09:57:24 f00b4r0: Great. I'll drop the revert in my staging tree and wait for his patch then. Apr 08 09:57:57 it's good to see that the vendor source was correct ;^P Apr 08 10:00:57 stintel: that's brilliant, no doubt rolled on the thighs of finely chopped virgins...or something like that :-) Apr 08 10:04:23 ldir: that's where the whole contribute to OpenWrt story started for me (2009) Apr 08 10:05:41 I think I was around 2015 'cos I was interested by cake. Apr 08 11:06:14 stintel: nice box! Apr 08 12:28:34 jow: I'd like to extend the realtime connections display to include the connmark field, not sure how to approach it - are you around by any chance to give some clues? Apr 08 12:29:45 am looking in connections.js - can't work out where updateConntrack: function(conn) gets its data from and hence what data is available. Apr 08 13:06:15 ldir: ubus call luci getConntrackList Apr 08 13:10:06 jow: thank you - now all I need to do is trial & error (mostly error) my javascript. It's fun learning a new language syntax for every idea that pops into the head :-) Apr 08 13:10:41 is the mark data in there already? Apr 08 13:10:54 yep, seems to be called 'mark' Apr 08 13:11:15 so I think I need to extend rows.push Apr 08 13:12:03 yes Apr 08 13:12:25 and you need to add another col in the thing from line 378 to 386 Apr 08 13:12:39 and the display bit which is one of the many E'div' Apr 08 13:13:38 success!!!! Apr 08 13:14:54 thank you!!!!! Apr 08 13:15:14 yw Apr 08 13:15:56 Now I need to get clever and interpret the mark value - I store the DSCP into the mark. Apr 08 13:17:58 mark is 32bit and dscp is 8, right? Apr 08 13:18:08 or 4 even Apr 08 13:18:11 so I'd like to decode the value into text, something like 'CS0, CS1, CS2' etc. Apr 08 13:18:12 6 Apr 08 13:18:34 and whats the encoding scheme? just the lowest 6 bit ? Apr 08 13:18:47 This is what my connmark -setdscp enhancement to iptables connmark is all about. Apr 08 13:19:22 In my case I store the DSCP into the TOP 6 bits of the connmark field. Apr 08 13:19:45 okay so dscp_value << 26 ? Apr 08 13:19:54 yes. Apr 08 13:20:20 I have 2 other flag bits in bit 24 & 25, Apr 08 13:20:43 so if you simply right shift by 26 you'll lose those :-) Apr 08 13:21:47 are the values correctly arriving in JS? Apr 08 13:21:59 or are they truncated? Apr 08 13:22:32 they're arriving correct. eg 3271557120 Apr 08 13:22:38 correctly Apr 08 13:22:50 unsigned no less! Apr 08 13:23:16 if you apply a triple left shift of 26 you should be able to get the correct dscp value Apr 08 13:23:23 3271557120 >>> 26 Apr 08 13:23:42 (>>> coerces the result into an unsigned 32bit int) Apr 08 13:24:03 the operand rather Apr 08 13:24:05 right shift? Apr 08 13:24:13 yes, right :P Apr 08 13:24:19 triple right Apr 08 13:25:14 ok, so then it's a lookup table into text Apr 08 13:26:19 the two flags should be readable by (3271557120 >>> 25) & 1 and (3271557120 >>> 24) & 1 respectively Apr 08 13:27:52 cool so a function that accepts the raw value and returns the correct text as per flags & lookup would seem the sensible way to go Apr 08 13:29:41 a total guess.. does c.mark.myMagicFunction() seem ok? Apr 08 13:29:49 I'm guessing at javascript syntax! Apr 08 13:37:19 ldir: that likely won't work Apr 08 13:38:11 ldir: declare a function decodeMarkValue(mark) { ... } before line 27 or so Apr 08 13:38:45 ldir: and simply invoke it as decodeMarkValue(c.mark) Apr 08 13:39:22 ok, thanks, will try that. - just building the lookup table Apr 08 13:58:36 * ldir yays - has something that works Apr 08 14:21:48 * ldir finess finess fiddle fiddle tweak tweak Apr 08 15:03:09 5.4.31 in my staging tree Apr 08 15:49:15 ynezz: Applying patch generic/184-USB-serial-option-add-Wistron-Neweb-D19Q1.patch Apr 08 15:49:15 patching file drivers/usb/serial/option.c Apr 08 15:49:15 Hunk #1 FAILED at 1990. Apr 08 15:50:06 are you using the maintainer scripts thing for that? seems weird you didn't trip over this yourself Apr 08 15:52:31 looks like the patch can be removed Apr 08 15:56:59 yes, using maintainer script myself Apr 08 15:57:53 it built fine from scratch for x86/64 https://gitlab.com/ynezz/openwrt/-/jobs/503853438 Apr 08 16:22:24 ldir: this is probably caused by dangole's recent commit Apr 08 16:23:06 ldir: aff965a415899efbd7ea409f5dbe5945227e245b Apr 08 16:24:10 don't get this 5.4 backports :) Apr 08 16:26:11 in theory, stuff that has come from 5.5 & 5.6....... Apr 08 16:49:56 in reality this stuff is from v5.4.29 Apr 08 16:50:15 according to `git tag --contains 4003d59a00e2b487184d54b5945bc3f15d18d894` Apr 08 16:54:50 thats probably why it's encouraged to name the backport patches with patch_index-kernel_version_origin-subject.patch naming scheme, so that 184-v5.4-USB-serial-option-add-Wistron-Neweb-D19Q1.patch would make it obvious to reviewer, that its not worth the additional hassle Apr 08 17:05:09 anyway, thank you for report, should be fixed now Apr 08 19:14:10 aparcar[m]: Reply-To: 20200405015929.736414-1-mail@aparcar.org in that `[PATCH v2] phase1: Add JSON merging step` ? Apr 08 19:17:21 I meant to be In-Reply-To Apr 08 19:17:41 awkward Apr 08 19:18:27 ynezz: what do you mean it wastes time? Apr 08 19:19:29 two patches instead of one, reloading buildbots every time Apr 08 19:19:51 what for? Apr 08 19:20:23 ynezz: fair Apr 08 19:20:41 did anyone send any comments to v1? Apr 08 19:20:56 ynezz: no Apr 08 19:22:53 ynezz: please tell me a target that still uses the old image generation code (aka wouldn't work right now with the JSON creation) Apr 08 19:38:00 ynezz: apu2 is running 5.4.31 :-) Apr 08 20:17:26 ynezz: I found a bug and sent a patch Apr 09 02:09:29 Does anyone here get "thermal_sys.ko" missing error when building kmod-hwmon-core with kernel 5.4? **** ENDING LOGGING AT Thu Apr 09 02:59:57 2020