**** BEGIN LOGGING AT Fri Jan 24 02:59:58 2020 Jan 24 06:47:45 that fq-pie thing is bizarre. I have no idea why it exists Jan 24 06:48:33 the point of pie is that it uses very little RAM. FQ increases it Jan 24 07:09:02 PKG_MIRROR_HASH fix in https://patchwork.ozlabs.org/patch/1226076/ Jan 24 07:09:44 how is it possible, that this hash mismatch could be undetected for such a long time? Jan 24 07:10:27 I mean, shouldn't this be detected by buildbots as they should refuse building of packages which have mismatched hashes? Jan 24 07:11:43 maybe the file was updated upstream, with the same name Jan 24 07:12:11 it doesn't matter I think Jan 24 07:12:39 its Git commit hash which should return always same result Jan 24 07:16:21 I don't understand this Makefile, sorry Jan 24 07:35:29 ynezz: multiple problems. sometimes the tooling changes. sometimes the environment changes. sometimes ??? Jan 24 07:36:18 there are a lot of locally generated tarballs at sources.openwrt.org with the wrong hash Jan 24 07:37:37 shouldnt we just force (enable by default) the hash checking and cleanup that mess? Jan 24 07:38:16 sure Jan 24 07:39:06 I remember two situations with PRs that generared the wrong hashes Jan 24 07:40:23 the first was superseded by hauke. the second was fixed by cotequeiroz. might have been the same issue Jan 24 07:40:49 many generic patches can probably just be dropped. such as: https://github.com/openwrt/openwrt/blob/master/target/linux/generic/pending-4.19/102-MIPS-only-process-negative-stack-offsets-on-stack-tr.patch Jan 24 07:40:53 whoops Jan 24 07:40:59 https://github.com/openwrt/openwrt/commit/8252511dc0b5a71e9e64b96f233a27ad73e28b7f#diff-c91b32109cb05bc5934af4f72b9a2ac4 Jan 24 07:42:12 wonder what other issues will eventually pop up... Jan 24 07:46:08 < mangix> there are a lot of locally generated tarballs at sources.openwrt.org with the wrong hash Jan 24 07:46:11 which ones? Jan 24 07:49:26 ynezz: if PKG_MIRROR_HASH does not match the downloaded file, buildroot will fall back to git cloning after a few attempts Jan 24 07:52:17 jow: ah, good :) Jan 24 07:56:15 BTW I hope it's not a problem to create release branches for projects, like for example openwrt-19.07 in procd, where I've backported only fixes Jan 24 07:56:30 no thats fine, we did that for a few compomnents in the past Jan 24 07:56:34 I've seen lede-17.01 in there, so I assume it's ok Jan 24 07:56:35 ok Jan 24 08:54:17 jow: ecdsautils is one that comes to mind Jan 24 09:37:00 ynezz: btw that ccs811 calculates equivalent of CO2, it doesn't actually measure it. I am not looking into scd30 Jan 24 09:38:09 s/not/now/ Jan 24 09:39:27 it's much more expensive though Jan 24 10:15:36 stintel: their SPS30 looks good as well Jan 24 10:17:47 ah for particulate matter Jan 24 10:18:22 guess I'll be ordering yet another bunch of sensors one of these days :P Jan 24 10:19:22 asked again for a quote for the 10gbe switch I was looking at. if it's not too crazy expensive I might also get that macchiatobin soon :P Jan 24 10:20:03 I actually had 2 double shots in my cart at farnell Jan 24 10:20:20 but decided it's useless as long as I don't have a 10gbe network Jan 24 10:37:05 blogic: fyi, I just bumped 5.4 to latest in my staging Jan 24 10:41:01 did you happen to figure out that kmod dependency thing yet? Jan 24 10:47:05 not yet. I hope to finally finish generic 5.4 next week Jan 24 10:47:55 I was a bit overloaded with daytime job this week Jan 24 10:48:44 those damn day jobs, always spoiling all the fun :P Jan 24 10:53:11 one of the things preventing me from moving my ubnt,bullet-m's from ar71xx to ath79 is the problem involving different SoC's in use (ar7240 vs ar7241) and broken ethernet if trying to use the same image on both. what's the right solution? Jan 24 10:58:45 stintel: I'm glad that my dayjob involves OpenWrt :-) Jan 24 10:59:11 I feel ya Jan 24 10:59:26 I've got a request from my boss to try to support nVidia TX2 hw in OpenWrt Jan 24 10:59:53 we temporarily used OpenWrt on 2 of our EOL watchguards to replace the even more EOL Cisco ASA crap we were using Jan 24 11:00:14 stintel: btw. do you still have that memory leak? Jan 24 11:00:16 but we have since bought new watchguards for our new office so no more OpenWrt at day job for me Jan 24 11:00:29 xback: I do Jan 24 11:00:37 but kmemleak is beyond useless Jan 24 11:00:48 I enable it and the thing suddenly needs 1GB of RAM to be able to even boot Jan 24 11:01:09 is it an Apple device? ;-) Jan 24 11:01:34 and /sys/kernel/debug/kmemleak is empty Jan 24 11:01:35 hahaha Jan 24 11:01:40 it's a qemu VM Jan 24 11:02:04 now since I had to give it 1GB to be able to boot with kmemleak enabled, it takes much longer to hit OOM with the leak Jan 24 11:02:15 total used free shared buff/cache available Jan 24 11:02:15 Mem: 990 706 218 14 64 216 Jan 24 11:02:19 after 67 days of uptime Jan 24 11:02:50 if you wanna have a look around I can add your SSH key on the device ? Jan 24 11:03:26 I'm really clueless how to debug this further Jan 24 11:05:18 stintel: I was thinking to maybe just install "netdata" package Jan 24 11:05:30 it has tons of metrics maybe showing a pattern Jan 24 11:06:07 wow that thing is on 4.19.52 Jan 24 11:06:18 maybe I should update it first lol Jan 24 11:32:34 aarrrghh! I mean drop 4.14 Jan 24 11:32:53 oops Jan 24 12:51:39 build #281 of ath25/generic is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/ath25%2Fgeneric/builds/281 blamelist: Petr ?tetiar , Koen Vandeputte , Kevin Darbyshire-Bryant , Jason A. Donenfeld , DENG Jan 24 12:51:39 Qingfang Jan 24 12:55:29 build #280 of octeontx/generic is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/octeontx%2Fgeneric/builds/280 blamelist: Petr ?tetiar , Koen Vandeputte , Kevin Darbyshire-Bryant , Jason A. Donenfeld , Jan 24 12:55:29 DENG Qingfang Jan 24 13:07:03 build #277 of brcm63xx/generic is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/brcm63xx%2Fgeneric/builds/277 blamelist: Petr ?tetiar , Koen Vandeputte , Kevin Darbyshire-Bryant , Jason A. Donenfeld , Jan 24 13:07:03 DENG Qingfang Jan 24 13:19:51 build #278 of oxnas/ox820 is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/278 blamelist: Petr ?tetiar , Koen Vandeputte , Kevin Darbyshire-Bryant , Jason A. Donenfeld , DENG Jan 24 13:19:51 Qingfang Jan 24 13:20:02 xback: any specific metric I should look at ? Jan 24 13:27:14 build #276 of at91/sam9x is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsam9x/builds/276 blamelist: Petr ?tetiar , Koen Vandeputte , Kevin Darbyshire-Bryant , Jason A. Donenfeld , DENG Qingfang Jan 24 13:27:14 Jan 24 13:28:47 hmm, ok, what have I done.. Jan 24 13:28:49 * ldir looks Jan 24 13:29:16 who controls this KBG-1 bot ? Jan 24 13:32:48 ahh! Jan 24 13:41:43 * ldir should be fixed Jan 24 13:42:32 24|14:42:25 Ignoring JOINS PARTS from KGB-1 Jan 24 13:42:50 just ignore them all :) Jan 24 13:43:02 stupid network is stupid. that amount of excess floods in such a short time should be auto-temp-klined Jan 24 13:43:17 karlp: I don't like talking to people who left :) Jan 24 13:43:51 in that case autocomplete doesn't work? Jan 24 13:44:15 it does, if you tabcomplete right before they leave but finish your typing after Jan 24 13:44:20 wouldn't be the first time Jan 24 13:44:49 fairy nuff Jan 24 13:44:56 24|14:44:49 -!- KGB-1 [~kgb@camembert.tina.pm] has quit [Excess Flood] Jan 24 13:44:57 ffs Jan 24 13:45:36 ah QUITS Jan 24 13:46:45 aarrrghhhh!! drop 4.14 - sorry delayed reaction Jan 24 13:46:58 =) Jan 24 13:58:15 build #265 of brcm47xx/generic is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/brcm47xx%2Fgeneric/builds/265 blamelist: Petr ?tetiar , Koen Vandeputte , Kevin Darbyshire-Bryant , Jason A. Donenfeld , Jan 24 13:58:15 DENG Qingfang Jan 24 14:15:00 oh ffs buggrit millenium hand and shrimp! Jan 24 14:21:16 build #262 of pistachio/generic is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/pistachio%2Fgeneric/builds/262 blamelist: Petr ?tetiar , Koen Vandeputte , Kevin Darbyshire-Bryant , Jason A. Donenfeld , Jan 24 14:21:16 DENG Qingfang Jan 24 14:22:40 owrt-snap-builds: yes I know, I'm test building a fix right now... after it turned out I built the wrong version before! Jan 24 14:22:40 What you say! Jan 24 14:22:57 owrt-snap-builds: no really. I am! ;-) Jan 24 14:23:23 Uh-oh, has the bot become sentient? Jan 24 14:23:55 * ldir hopes so Jan 24 14:37:01 owrt-snap-builds: there you go, I've pushed a fix, go and try it Jan 24 15:20:35 personal preference, wpad-full or hostapd-full Jan 24 15:20:49 wpad Jan 24 15:21:15 how come Jan 24 15:22:48 then I don't have to build a new image whenever I decide I want to use a device in client mode vs AP Jan 24 15:25:13 what about using wpa-supplicant-full with hostapd-full Jan 24 15:25:32 does that even work? Jan 24 15:25:43 isn't the whole purpose because they can't both have the radio at hte same time? Jan 24 15:25:57 why would you do that if wpad-full offers you both? Jan 24 15:34:49 and that :) Jan 24 18:36:00 I intersted in having a custom firmware built that will match up the ssid with the sticker on the router. for example the last 4 of the mac address is 01f3, the default ssid might be set to "SomeName_01f3" when the router is factory reset. If someone is intersted in some contract work for money hit me up. Jan 24 18:37:01 db8393: do you need just that, having SSID by default postfixed with two last octets from the MAC? Jan 24 18:38:09 Based on current master and assuming the device properly sets label_mac in its DT? Jan 24 18:38:11 Yeah, and maybe a little help with a way to remote provision using something simple (hopefully). Something like the router phones home and grabs config files Jan 24 18:38:33 https://patchwork.ozlabs.org/patch/1191834/ Jan 24 18:38:39 Essentially it should be that Jan 24 18:39:39 You want to help us for payment? We are trying to do this fast and are happy to hire you to implement it Jan 24 19:52:37 build #250 of x86/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeneric/builds/250 Jan 24 20:01:11 * ldir returns after a 4+ hour drive from the North of England to home. Looks like buildbot is no longer unhappy with me Jan 24 20:01:40 lol Jan 24 20:14:16 the ssid part of that is nice and clear and well defined, the "a little help with some remote provisioning" is a massive ball of string :) Jan 24 20:17:36 exactly. Jan 24 20:25:52 karlp: not really that well defined. Because they might be using just devices where label_mac is provided by DT and hence it's easy to do without races guaranteed. Or not. Jan 24 20:27:33 I'd probably try talking to them to see what they really require but I think adrianschmutzler is in a better position to do that. Looks like a reasonably nice opportunity for a contract work. Jan 24 20:28:05 I've already had contact. Though I will only do the SSID stuff Jan 24 20:31:02 Cool Jan 24 20:31:35 Yes, particularly since I'm not used to contracted work Jan 24 21:00:09 PaulFertser: nah, for a known set of devices, you can just hardcode it, label device mac or not. Jan 24 21:18:43 ... Jan 24 21:18:55 long day time for the first episode of Picard Jan 24 21:19:17 and thansk to my new gpon line even in HD Jan 24 21:19:18 :-D Jan 24 21:24:52 xback: https://paste.centos.org/view/370b60a2 fixes the kmod-ecdh -> ecc+ecdh split. You can treat that as public domain if it's easier to squish it any way. Jan 24 22:01:30 karlp: if You'll have additional problems: https://paste.debian.net/1126975 Jan 24 22:13:02 nope, don't need ath10k :) Jan 24 22:15:43 though you did a DEPENDS:=@LINUX_5_4 for the kmod-ecc, which probably makes more sense than me Jan 24 22:16:51 note that you should invert that at some point if you want to merge it Jan 24 22:17:11 !(@4.19 || @4.14) Jan 24 22:17:33 hrm, arc4 looks like it might give me headache later too. Jan 24 22:20:18 yeah, that patch is very dirty, but did the job. Jan 24 22:21:00 and it might be that I didn't do it correctlly Jan 24 22:23:51 and that arc4 might be better as compilled in kernel Jan 24 22:25:19 Looks like I should change all those @!LINUX_4_19 to @LINUX_4_14 at some point Jan 24 22:27:33 for me that's a matter of taste, if it's correct don't overwork yourself Jan 24 22:28:27 tmn505: well, the goal is special case the bad old things, not special case all the stuff that's going to be "normal" Jan 24 22:28:43 of course, but generally it's better to have the "old" kernels stated explicitly, as this will make adding new kernels easier Jan 24 22:29:06 as karlp says Jan 24 22:29:23 good point Jan 24 22:41:26 just sent a patch Jan 24 22:42:05 having removed 4.9 makes it quite easy ... Jan 24 22:45:25 this should make the pasted patch much easier, and as said earlier one should then replace LINUX_5_4 by !(LINUX_4_19||LINUX_4_14) there to have the same benefit in the future Jan 24 22:47:58 damn you're fast :) Jan 24 22:48:53 Prevents me from doing something useful I do not want to at the moment ;-) Jan 24 22:49:04 know that feeling :) Jan 24 22:50:02 ffs, 5.4 is still incompatible with my backported 5.5 dts. Jan 24 22:50:11 thought this stuff had gone in before 5.4, but noooo Jan 24 22:50:22 adrianschmutzler: it's called structured procrastination! Jan 24 22:50:29 very useful thing in life :) Jan 24 22:55:05 I still doubt that ;-) **** ENDING LOGGING AT Sat Jan 25 02:59:59 2020