04:13 <IgorPec> good morning

04:15 <nekomancer[m]> goodmorbibg

15:35 <Werner> What to do when bored at work? Start writing a Python script that hopefully will help to refactor patch folders

15:35 <Werner> #donttellmyboss

16:05 <IgorPec> Werner: :)

16:05 <IgorPec> Werner: this https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md

16:06 <Werner> ?

16:06 <IgorPec> if you are bored ...

16:07 <Werner> Um...I'll stick to the script for now :P

16:07 <Werner> https://github.com/EvilOlaf/refactorpatches messy enough

16:07 <IgorPec> hehe :) what is the idea about those scrits?

16:08 <Werner> Collect information about which files are targeted by a patch and merge them as a first step

16:13 <Werner> So I know that board-h5-add-0000-nanopi-k1plus.patch, board-h5-add-0001-nanopi-neo-core2.patch, board-h5-add-0002-nanopi-neo2-v1.1.patch, oard-h5-add-0003-nanopi-m1-plus2.patch and general-sunxi-overlays.patch are patching the same file

16:13 <ArmbianTwitter> @armbian (armbian): RT @RoganDawes: I wrote up Part 1 of my "Making the Perfect Red Team Dropbox" series. This uses the @FriendlyARM_ NanoPi R1S as a USB attac… (6s ago)

16:13 <Werner> they all change something at arch/arm64/boot/dts/allwinner/Makefile

16:14 <IgorPec> yes. it is usefull to know which patches can be merged together ... like "enable wifi on opizero" with "enable dvfs on opi zero"

16:15 <Werner> Yes. Also I have 5 patches that targeting sun50i-a64-pine64.dts

16:15 <Werner> *6

16:15 <Werner> But well, you get the point ^^

16:16 <IgorPec> yes. we should open a Jira on this topic

16:16 <Werner> It is partically functional already. Have to manually edit the target folder. It will search all patches and break down patches with multiple targets into individual files. Then collect information about the target file and link it to the patch file and print it.

17:20 <Werner> Is there a known issue with H3 SoC that it freezes after 2-3 days? I thought I read something somewhen somewhere...

17:24 <IgorPec> without any load?

17:25 <IgorPec> if we have a patter than can easily be recreated and there are chanches we will be able to do something, collect info and open Jira

17:25 <Werner> Pihole if you can call that a "load". Just got a message from a friend that his One dies after two and a half days, with fresh image as well. Though slightly outdated with 5.4.20. Was just thinking...

17:25 <IgorPec> i mean its possible, but one sample is not enought to do anything

17:26 <Werner> Of course not since mine is running fine and currently has a uptime of 18 days with 5.4.36

17:26 <IgorPec> in 90% its something else

21:18 <lanefu> stability varies :P

21:18 <lanefu> lane@hambone:~/GIT/lanesible$ ansible hashi_cluster -m command -a 'uptime' -o

21:18 <lanefu> armdocker-2.angrybear.com | UNREACHABLE!: Failed to connect to the host via ssh: ssh: connect to host armdocker-2.angrybear.com port 22: Connection refused

21:18 <lanefu> armdocker-1.angrybear.com | CHANGED | rc=0 | (stdout) 17:18:01 up 22 days, 21:04, 1 user, load average: 0.78, 0.65, 0.48

21:18 <lanefu> armdocker-3.angrybear.com | CHANGED | rc=0 | (stdout) 17:18:01 up 15 days, 4:04, 1 user, load average: 0.28, 0.31, 0.34

21:19 <lanefu> I've seen the clock change problem before, but it's been really hard for me to capture...

21:19 <IgorPec> where?

21:19 <IgorPec> which hw?

21:19 <lanefu> those are all orangepi plus 2e...h3

21:19 <IgorPec> ahaa, and they are failing?

21:20 <IgorPec> huh. its possible that there are some issues with h3

21:20 <lanefu> yeah they go offline on occasion... ping still works, but dont respond otherwise... i had kind of always assumed maybe it was the work load... but i think the clcok change could cause them to not answer ssh

21:21 <IgorPec> what if you set fix speed?

21:21 <lanefu> like i even setup log shipping

21:21 <IgorPec> try that

21:21 <lanefu> and i didnt get any good data

21:21 <IgorPec> i suspect its related to dvfs

21:21 <lanefu> hmm okay

21:21 <IgorPec> it also happened to me in the test rig

21:22 <IgorPec> also i could recreate yesterday on Nanopi neo v1 ... reaching 100 degress followed by shutdown

21:25 <lanefu> lane@hambone:~/GIT/lanesible$ ansible hashi_cluster -m shell -a 'uname -rv;uptime' -o

21:25 <lanefu> armdocker-2.angrybear.com | CHANGED | rc=0 | (stdout) 5.4.2-sunxi #19.11.3.342 SMP Sat Dec 7 13:34:37 EST 2019\n 17:24:57 up 2 min, 1 user, load average: 1.16, 0.75, 0.30

21:25 <lanefu> armdocker-3.angrybear.com | CHANGED | rc=0 | (stdout) 5.5.14-sunxi #trunk.094 SMP Fri Apr 3 01:11:05 CEST 2020\n 17:24:57 up 15 days, 4:11, 1 user, load average: 0.86, 0.50, 0.39

21:25 <lanefu> armdocker-1.angrybear.com | CHANGED | rc=0 | (stdout) 5.4.2-sunxi #19.11.3.342 SMP Sat Dec 7 13:34:37 EST 2019\n 17:24:57 up 22 days, 21:11, 1 user, load average: 0.63, 0.59, 0.51

21:25 <lanefu> but see... i've got 2 running same kernel, adn one has been up for 22 days, and the other.... 2 min :)

21:27 <lanefu> let me see if i had some temp data

21:27 <IgorPec> yeah, it is very weird issue since otherwise there will be more complains

21:29 <lanefu> yeah.. its been going on for like 2 years.. i just restart them and figured it was me :P

21:43 <IgorPec> are we ready for .1 ?

22:58 <nekomancer[m]> 1.0