**** BEGIN LOGGING AT Thu Nov 12 02:59:56 2020 Nov 12 03:15:44 Can someone tell me why this doesn't work? https://gist.github.com/Grommish/ea9488237e3b19dbb721d3e62b901b68 I'm missing something simple but I dunno what Nov 12 03:17:12 Sorry.. https://gist.github.com/Grommish/ea9488237e3b19dbb721d3e62b901b68#file-gistfile1-txt-L18 Nov 12 04:41:47 build #110 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/layerscape%2Farmv8_64b/builds/110 Nov 12 06:19:43 Grommish: you do not have \\ in that shell script snippet Nov 12 06:20:28 You can't have just multiline shell script part like that in a Makefile afaik. Nov 12 06:20:56 I'll check that here when the build gets done Nov 12 06:21:06 I apprecate it :) Nov 12 06:21:45 Add semicolons and \ and it should work Nov 12 06:36:59 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.) Nov 12 07:01:06 PaulFertser: I'll let you know :) I've been staring at this for far to long.. and each time it runs, it takes 2 hours before i know if it fails :D Nov 12 08:27:12 aparcar[m]: Sorry I didn't pong, I had gone to sleep already. Anyway: https://patchwork.ozlabs.org/project/openwrt/patch/20201111235337.1450434-1-rsalvaterra@gmail.com/ Nov 12 09:23:25 nitroshift: o/ Nov 12 09:23:38 rsalvaterra, hey! Nov 12 09:24:12 I remember another possibility for your mamba… but you're probably not going to like it. :P Nov 12 09:24:33 First of all: do you have a serial console? Nov 12 09:24:43 rsalvaterra, of course Nov 12 09:24:59 Ok… you could try to build the kernel in Thumb-2 mode. Nov 12 09:25:33 rsalvaterra, that could be an idea but there's no point Nov 12 09:25:38 If you're lucky, you'll be able to build the kernel with -O2 and still be able to fit it in the 3 MiB partition. Nov 12 09:26:08 i'll keep my mamba's on 5.4 and call it a day Nov 12 09:26:10 :) Nov 12 09:26:19 after all, they're only back-up devices Nov 12 09:27:06 the only nice thing about them is that the radio cards are pci-e, not soldered Nov 12 09:27:40 Really? That's news to me. :O Nov 12 09:27:43 at the time i was using them with ath9 cards, rock-solid Nov 12 09:28:04 hell, i think one of them is still in that configuration :)) Nov 12 09:28:30 rsalvaterra, yeah Nov 12 09:28:55 all subsequent devices though came with soldered radios :( Nov 12 09:30:31 let me know when you got a chance with the patches Nov 12 10:13:02 good morning Nov 12 10:13:16 https://elixir.bootlin.com/linux/v5.10-rc3/source/Documentation/devicetree/bindings/arm/l2c2x0.yaml#L42 Nov 12 10:13:31 marvell controller?? Nov 12 10:46:39 Hauke: looks like layerscape buildbot was successful Nov 12 11:30:32 so I've following DSA config on rtl838x http://sprunge.us/czZP2W Nov 12 11:31:05 if I put two different devices into lan9 lan10 ports and start ping between them it works Nov 12 11:31:30 then I remove one device from lan9 port (vlan 140) and ping stops as expected Nov 12 11:32:09 so I connect the device into port lan17 (vlan 150) and the ping starts working again for some time, then stops, which is quite unexpected Nov 12 11:32:59 actually I don't need to use vlans (IIUC DSA correctly), but it behaves the same with or without vlans Nov 12 11:34:36 I'm just looking for some solution for my testbed, where I've two testing devices 1. apu2 2. cdrouter and multiple DUTs (devices under test) Nov 12 11:35:50 DUTs are Netgear RAX40 (rax40), TP-Link Archer C7v6 (archer-c7v6) for example Nov 12 11:36:55 I want to control the network in the testbed from CI runner, probably via some API (rpcd or such) or for the start just over SSH Nov 12 11:37:50 so I can connect testing equipment like apu2 with the DUT, usually it's WAN, LAN1 and LAN2 from the DUT connected to the testing equipment Nov 12 11:39:41 in ideal scenario I would like to be able to run multiple CI jobs in paralel, so this would mean, that testing equipment(TE) 1 is connected to DUT 1, TE2 to DUT2 etc. Nov 12 11:40:52 the dependencies would be handled on the CI side, so no need to worry about the reservations/clashing of the network configs Nov 12 11:43:47 so in essence, something like `ssh root@testbed setup_network te1 dut1` (and it would connect the te1 with dut1 over various switch ports to interconnect WAN,LAN1,LAN2 properly) Nov 12 11:44:40 I'm not networking guy, don't want to reinvent the wheel, so wondering if there is something already available for such stuff, ideally packaged for OpenWrt Nov 12 11:46:11 Someone looked at Netgear GC110 cloud switches? I see that you can get them really cheap. € 30,-- for 10 port switch 8x port ethernet and 2x SFP ports. Nov 12 11:46:58 Rene__: https://biot.com/switches/models and #rtl838x Nov 12 11:51:41 I don't think GC110 GS110 are the same. The datasheet talks about an 400MHz Cortex-A9 ARM instead of a MIPS cpu. Nov 12 11:59:44 ah, sorry then, C/S Nov 12 12:26:37 ynezz: No problem. Thanks for the info. I wonder what kind of firmware format they are using. Firmware image has the stk extention but I can't find any other info on the web or any GPL sources. Nov 12 12:32:47 Rene__: the stk FW files are for Broadcom platforms Nov 12 12:33:24 and the GC110 is definitely Broadcom Nov 12 12:35:51 svanheule[m]: thanks Nov 12 12:36:33 Looking for anything specific? Nov 12 12:38:34 No, I saw that they are really cheap for a switch with SFP ports. Also POE version is € 50,-. Nov 12 12:40:06 I think you have to buy an Insight subscription after a year to keep using these switches, maybe that's why the retail prices are lower than for other switches Nov 12 12:40:09 But I was wondering if the switch was opensource or at least see that GPL code was available. But that is not the case. Nov 12 12:40:51 There is some code at https://kb.netgear.com/2649/NETGEAR-Open-Source-Code-for-Programmers-GPL Nov 12 12:41:09 Probably not very useful, knowing Netgear's GPL archives... Nov 12 12:43:19 I think my next switch should have aleast 1 or 2 SPF+ 10Gbit ports and some multi-gigabit ports. Nov 12 13:12:46 There's the Zyxel XGS1930, but I don't know how far along the support is https://biot.com/switches/zyxel_xs1930_series Nov 12 13:13:25 also a lot more expensive than that GC110, but that goes for all multi-gig switches, I think Nov 12 13:13:27 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 100.0% packages reproducible in our current test framework.) Nov 12 13:20:11 correction: XGS1930 is GbE + SFP+, XS1930 is N-BaseT + SFP+ Nov 12 15:41:25 ynezz: ping Nov 12 15:42:55 adrianschmutzler: timeout Nov 12 15:42:57 :) Nov 12 15:43:10 hi, btw Nov 12 15:44:05 I just put together a patch to create a separate Mi Router 4a Gigabit, maybe it would be easier if I took over the corresponding uboot-envtools patch and added the 4a there on top of my current tree? Nov 12 15:44:26 And you just drop it ... Nov 12 15:44:33 adrianschmutzler: sure, thanks Nov 12 15:45:02 okay, perfect. Nov 12 15:45:04 next time just do it directly on GH, assign it to yourself Nov 12 15:45:25 I've script which is merging just PRs assigned to me and marked as `ready for merge` Nov 12 15:46:31 I decided to pick up the 4a subject relatively late and when I remembered the connection to "your" PR, you already picked it ... Nov 12 15:46:39 ah, ok Nov 12 15:47:45 I found that it's easier to split the device myself (in contrast to explaining how the DTSI split should be done), and then the guy in the other PR can apply whatever changes he has on top ... Nov 12 15:47:58 done Nov 12 15:49:02 BTW thanks for the corrections Nov 12 15:49:29 if I see PR in a good state without `changes needed` or other stuff, I consider it ready Nov 12 15:50:01 and not going over those hundreds of comments again Nov 12 15:50:17 if it compiles, ship it :) Nov 12 15:50:35 I actually think it's quite hard to find a good policy for using "needs changes" Nov 12 15:50:57 for me its opposite for `ready for merge` Nov 12 15:51:11 I typically hesitate to use it after first review if the commit generally seems okay, i.e. the guy seems to know what he's doing Nov 12 15:51:24 although there might be minor flaws that need to be corrected Nov 12 15:51:54 with 200 commits its quite hard to filter those Nov 12 15:51:55 since I've observed that a "needs changes" applied once is rarely lifted later Nov 12 15:52:10 particularly if the PR becomes old Nov 12 15:52:24 I'm going over those in other batches Nov 12 15:53:40 it would be nice to come with some automatic cleanup as discussed previously many times Nov 12 15:53:49 maybe it would be a good topic for next meeting Nov 12 15:54:10 yes, though this would probably help for many things but not "needs changes" Nov 12 15:54:38 if there is no comment/commit after `needs changes`? Nov 12 15:54:49 then it's stale Nov 12 15:54:55 stale -> closed Nov 12 15:54:59 or? Nov 12 15:55:21 okay, yes. that of course. That's just somehow different to the issue we discussed. Nov 12 15:55:38 do you've some example? Nov 12 15:56:10 I rather see the problem of "needs changes" where there is some activity of the author but it's just forgotten because the commit became old Nov 12 15:56:30 since there are not many people looking at these Nov 12 15:56:41 because there is a lot of useless noise, like people think its forum Nov 12 15:57:02 which essentially was only my point for not putting a "needs changes" in the first place for minor flaws Nov 12 15:57:18 but then I jump in that PR and find it's not ready Nov 12 15:58:01 essentially, that's a point where we would need to define a policy for when these labels should be used Nov 12 15:58:16 which we will have to do anyway when we use more automation Nov 12 15:58:44 to me `needs changes` means it's not ready for merge Nov 12 15:59:21 I don't want to have `needs slight changes` :) Nov 12 15:59:23 so, from your point of view, the first committer looking at the PR should use that unless he thinks it's ready for merge Nov 12 16:00:26 or `needs reviewer` if not able to decide Nov 12 16:01:40 I will have to think a little how this matches my review patterns; since I frequently only do partial reviews only Nov 12 16:02:27 is it possible to filter by number of comments? Nov 12 16:02:42 no idea Nov 12 16:04:31 But I do not have a problem with using "needs changes" according to your concept if that's helping you to spend less time Nov 12 16:05:00 I'm now doing it manually, but I hope, that some day it's going to be automatic Nov 12 16:05:11 like the formal stuff checking etc. Nov 12 16:06:45 what would you suggest instead? Nov 12 16:07:18 no, I'm fine with that Nov 12 16:07:28 my point was more about the immediate future Nov 12 16:07:29 don't even add the label if it's not ready for review? Nov 12 16:07:56 so there would be PRs without any label, unless touched for the first time? Nov 12 16:08:44 My idea of "needs changes" was more like it implied substantial changes Nov 12 16:09:23 that's same for patchwork Nov 12 16:09:40 And I think it was actually used like that in the past (or some people just didn't use it at all) Nov 12 16:10:42 And if other people think like that, the label will increase the chance of a PR being buried Nov 12 16:10:54 with patchwork, you either do all the small changes yourself or ask the author with "changes requested" Nov 12 16:11:09 there is nothing in between Nov 12 16:11:47 with github we miss the v2 from email Nov 12 16:12:09 but this could be automated, like if there was some activity after this label, we can remove that label Nov 12 16:12:13 or such Nov 12 16:12:22 Well, patchwork is somewhat a different szenario Nov 12 16:12:44 `needs changes` -> pushed in the PR branch -> `needs changes` removed Nov 12 16:13:15 hmm Nov 12 16:13:44 or the comment from author could remove that `needs changes` Nov 12 16:13:53 So, essentially apply the patchwork concept onto GitHub Nov 12 16:14:16 if the `needs changes` label passes certain period of time, mark it as `stale` then close Nov 12 16:14:19 new submission -> new evaluation Nov 12 16:14:50 GH is slightly easier as you can see the diff to previous Nov 12 16:16:42 This could work, at least it would be better than the current scheme where everybody uses "needs changes" differently Nov 12 16:17:05 automation should be limited to comments by the author though Nov 12 16:20:32 yeah Nov 12 16:22:14 what should I do with PRs where I have reviewed 50%, but cannot review the other 50? "needs reviewer"? Nov 12 16:22:57 I do so Nov 12 16:23:07 as I'm not going to merge it myself Nov 12 16:31:14 speaking of stale submissions, any chance that my patch (patching my own code) could be merged? :) https://patchwork.ozlabs.org/project/openwrt/patch/20200824103840.38920-1-hacks@slashdirt.org/ Nov 12 16:34:27 f00b4r0: probably the fastest would be to try lynxis again ... Nov 12 16:34:39 ok Nov 12 16:34:53 from the history, he already had a look? Nov 12 16:35:11 I certainly won't touch this Nov 12 16:35:25 he did, said he'd merge, then it died out Nov 12 16:36:06 then xback said he'd merge, and that too never happened ;^P Nov 12 16:36:18 but one of these two it will be Nov 12 16:36:23 ok Nov 12 16:37:27 I'm a little sick of all these mikrotik peculiarities anyway Nov 12 16:37:34 heh. Can't blame you Nov 12 16:37:50 they're making really hard to cope with. Nov 12 16:38:23 I kind of tried to create a foundation for support in ath79, and that is mostly achieved by now I think. Nov 12 16:38:32 true Nov 12 16:38:33 Apart from the open issues where I can't help. Nov 12 16:49:07 Speaking of stale things… is anyone taking a look at my procd patches? :) Nov 12 17:07:31 so, as long as I chose a package as built-in, its InstallDev will always be included into SDK/Toolchain correct? I included libnetfilter-queue under menuconfig, and can find libnetfilter under build/target, but they did not show up in SDK, i.e. the InstallDev from its Makefile did not help, am I missing something Nov 12 17:13:18 rr123: the produced SDK will always be lean, it will not contain any package ressources, just the toolchain Nov 12 17:13:42 f00b4r0: merged Nov 12 17:13:50 ynezz: thx! :) Nov 12 17:14:21 with so many tested-by: it's quite a pleasure Nov 12 17:14:36 I plan to look at patchwork in the upcoming days Nov 12 17:14:54 maybe I should predict more often that something won't happen :-) Nov 12 17:15:10 what do you mean? Nov 12 17:15:11 jow: thanks, what's the point of InstallDev then? in my case, libnetfiter's InstallDev did not do anything to SDK/Toolchain Nov 12 17:15:47 ynezz: just because I said probably only lynxis or koen will merge that Nov 12 17:16:11 ah, no worries about that Nov 12 17:16:13 I need libnetfilter-queue.so to build, trying to make code a package now, was trying to build within sdk but then found SDK does not have the InstallDev stuff Nov 12 17:16:43 maybe the 4k sector patch also gets merged if I tell now that it probably won't ;-) Nov 12 17:16:55 I'm about to push Nov 12 17:17:05 adrianschmutzler: lol :) Nov 12 17:17:20 rr123: the point of InstallDev is to stage header files and libaries in the staging directory so that other packages can pick them up Nov 12 17:18:25 in that case I might just set gcc to staging directory directly instead of using SDK/Toolchain then, will try now Nov 12 17:18:36 is option macaddr broken for wifi-device in 19.07 or am I just to stupid to use it? Nov 12 17:20:22 remote: No matching SoB line found for author Roman Kuzmitskii , gah Nov 12 17:21:05 Heads up: something in the last commits broke my VLAN setup. Nov 12 17:21:21 ynezz: it would be worth introducing CI just for this single issue Nov 12 17:22:50 I don't know if only switchdev devices are affected, haven't tested DSA. Nov 12 17:23:09 But my Archer C6 was definitely affected. Nov 12 17:23:59 I'm almost sure the cause is somewhere in the last netifd update. Nov 12 17:25:02 rsalvaterra: the changelog at least sonds like it Nov 12 17:26:22 adrianschmutzler: I don't know what happened. VLAN 1 (eth0.1, the LAN side) was configured correctly. VLAN 2 (eth0.2, the WAN) wasn't. Nov 12 17:31:08 I'm going to revert the netifd update and see this fixes it… Nov 12 17:44:30 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 100.0% packages reproducible in our current test framework.) Nov 12 17:59:01 * lynxis puts on his openwrt hat Nov 12 18:12:19 /o\ Nov 12 18:16:08 jow: are you fear my commits ;P? Nov 12 18:46:21 adrianschmutzler: Guess what? Bingo. Reverting the netifd changes fixed the problem. Nov 12 18:47:07 Is there anything wrong with my switch configuration? https://paste.debian.net/1172062/ Nov 12 18:47:44 So, would someone with commit access please unfsck master? Nov 12 19:38:35 lynxis: that hat looks good on you Nov 12 19:39:13 rsalvaterra: thanks for the sstrip patch, I'll give it a try later today. Are there any notable changes from our intree version? Nov 12 19:39:33 aparcar[m]: 'morning! ;) Nov 12 19:39:57 Zero changes, that I have noticed. And that's good! Nov 12 19:40:17 Tested on two MIPS devices. Nov 12 19:43:03 I'm doing my builds with sstrip -z. I haven't noticed any size differences, but I was only paying attention to the size of the final image, which is padded. Nov 12 19:47:56 ynezz: ping Nov 12 19:54:51 Anyone with bash tell me why this isn't working? https://gist.github.com/Grommish/384f9e9717ddf865164b932a5ef70bd7 It's always triggering the info statement Nov 12 19:55:05 ynezz: regarding the checkpatch commit, I like this script more as it doesn't require us to maintain anything on our own https://github.com/openwrt/openwrt/pull/3250#issuecomment-668461853 don't you prefer that as well? Nov 12 19:56:01 Grommish: $(foobar) will be evaluated no matter what and then executed if your hashes don't match Nov 12 19:56:21 try something like [ a == b ] || info "trouble" Nov 12 19:56:35 That's what you have Nov 12 19:56:41 those are hard-coded hashes righ tnow Nov 12 19:56:44 and it still fails Nov 12 19:56:58 I can't get a simple string compare to actually work for some reason Nov 12 19:57:32 don't use the $() Nov 12 20:00:06 I edited the gist to show what I'm using Nov 12 20:00:10 and the output Nov 12 20:09:34 Grommish: as said before, why do you wrap everything in $() Nov 12 20:11:35 Where?? Nov 12 20:13:39 Nevermind it's Makefile not Bash Nov 12 20:13:45 Right Nov 12 20:14:31 the [ ] just refuses to work for -eq or == for some reason.. or -ne Nov 12 20:14:34 and I don't know why Nov 12 20:14:47 INTEGER1 is equal to INTEGER2 Nov 12 20:14:59 I think you want to use just = Nov 12 20:15:19 == is bash style (not posix shell) and -eq is for numbers Nov 12 20:15:40 Ok.. i know [[]] is a no go for the same reason Nov 12 20:15:58 it's still just falling through.. how.. odd Nov 12 20:16:54 even: [ "a" = "a" ] || $(info No Match) is failing and stillshowing no match Nov 12 20:18:01 Ah well.. I'll just step away and pick it up later :) Nov 12 21:36:27 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.) Nov 12 22:11:03 Hmm… DNS cache poisoning is back. https://789498207.www.saddns.net/ Nov 12 22:14:21 Actually, https://www.cs.ucr.edu/~zhiyunq/SADDNS.html Nov 12 22:30:38 aparcar[m]: ping Nov 12 23:53:19 rsalvaterra: pong. Nov 12 23:53:33 I just noticed the old sstrip version removed trailing zero bytes by default, while the current version 3.1a doesn't. We should probably add the -z argument by default. Nov 12 23:54:06 I can do this as a follow-up patch, if you prefer. **** ENDING LOGGING AT Fri Nov 13 02:59:57 2020