**** BEGIN LOGGING AT Tue Jan 08 02:59:57 2019 Jan 08 04:25:46 build #724 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_64b/builds/724 Jan 08 04:44:57 *yawning* Jan 08 04:52:10 Morning blogic Jan 08 04:52:22 Early start? Jan 08 05:05:40 Monkeh: alarm went at 4:30 Jan 08 05:05:49 about to board Jan 08 05:05:52 oof Jan 08 05:06:00 Off somewhere or coming back from somewhere? Jan 08 05:06:01 yarp Jan 08 05:06:05 offski Jan 08 05:06:19 Anywhere nice? Jan 08 05:06:29 an office Jan 08 05:06:40 Oh, so not a nice holiday then. :P Jan 08 05:06:47 not really Jan 08 05:07:01 there is the boarding call Jan 08 05:07:05 back in 6 hours Jan 08 05:07:06 :( Jan 08 05:07:11 I feel your pain Jan 08 05:07:15 Just back from NC. Jan 08 08:56:00 mkresin: oh my... what's up with your SSD? Jan 08 09:34:42 guess I'll keep doing btrfs raid1 when replacing my 2xSSD+2xHDD w/ bcachefs combo with SSD only in my workstation next month Jan 08 09:36:12 stintel, how's bcachefs? Jan 08 09:37:09 oops, that should have been just bcache Jan 08 09:37:15 ah Jan 08 09:37:18 sorry Jan 08 09:37:34 but that makes /home on spinning rust a bit more bearable Jan 08 09:39:23 testing bcachefs as well but on another device, having some weird issues there. e.g. when copying a large file to it (say +10GB), at some point load avg starts going through the roof (seen 100+), copying slows to a crawl, and eventually fails with ENOSPC Jan 08 09:39:45 anybody tried bcache on intel optane hardware? Jan 08 10:04:22 What is the projects attitude towards tests of shell scripts? Are there any automatic tests of shell scripts in the openwrt project? Jan 08 10:07:25 rmilecki: the ssd locks up after 30s. could be worse. I'm able to dd a 5GB chunk, remove power, next 5Gb chunk. all recent data are already recovered :-) Jan 08 10:08:18 Jakkvurt: what's the actual question? Jan 08 10:08:44 mkresin: ddrescue ? Jan 08 10:15:33 karlp: Are there any automatic tests of shell scripts? Are there any existing methods for creating such tests? Is there any intention to have unit/integration tests for shell scripts? I wish to make contributions to some of the scripts in the project without breaking existing functionality. Jan 08 10:29:54 mkresin: wow Jan 08 10:30:01 mkresin: you're lucky :) Jan 08 10:30:19 mkresin: after switching to the notebook with SSD i've actually taken care of a proper backup Jan 08 10:30:28 first time in my life a real proper backup of all data I need Jan 08 10:30:41 i wish i've learned rsync earlier, it's awesome Jan 08 10:53:52 Hey can someone help me with uboot on lantiq? Jan 08 10:59:20 rmilecki: I'm doing syncthing to sync important directories from my laptop to my workstation; the latter has daily rsnapshot backup Jan 08 11:05:17 mkresin: That's an.. interesting failure mode Jan 08 11:14:01 Jakkvurt: I'm not aware of any already erally, I think as long as you made sure nothing was included in the resulting binaries you should be fine, Jan 08 11:14:23 just make your changes, it's easier to see that way than answer abstract questions like this Jan 08 11:19:38 karlp: Sure. Just wish to avoid bloating the project with duplicate test harnesses. I will implement it as best I can, take feedback in PR. Jan 08 11:21:21 jwh: are you daniel? (you should really mail your patches properly even if they're experimental, just so people have a look at them) Jan 08 11:22:21 I'd say at the very least, it needs to be something tha tyou can turn on and use, not that yuou have to turn on, build, then turn off again and change anotehr config to match that path Jan 08 11:26:12 last time I've noticed some discussion here regarding this topic, that it would be nice to have kernel sources in Git completely instead of this patch files Jan 08 11:29:16 a few people suggested it, it was shot down pretty hard though, when it was explained a little more what that would actually mean. Jan 08 11:29:41 it would make everything bigger and harder for more peopel in teh general case, so that it would be easier fora few people in special cases. Jan 08 11:29:47 there was a lot of detail in the thread Jan 08 11:30:13 ah, ok Jan 08 11:30:33 ynezz: it's quite a big amount of non-trivial work, as we don't have just patches, but also directly copied files shared between kernel versions that get modified by patches, and non-mbox patches for which the git/svn history would need to be checked for proper authorship/attribution Jan 08 11:33:21 stintel: doesn't work if the sdd doesn't accept any SATA commands any more Jan 08 11:35:10 die Nachricht hat der Lieferdienst komplett zeruppt. alle zeilenumbrüche rausgefegt, keine klammern und ajede zeile zentriert Jan 08 11:35:15 damemd Jan 08 11:35:54 KanjiMonster: I didn't said it's an easy task :) I don't even have complete picture to suggest some solution, but I just know, that it would make development, upstreaming, backporting easier (maybe) Jan 08 11:38:21 ynezz: not really. due to each target having its own set of patches/files, we essentially don't have one openwrt kernel, we have (amount of targets) different openwrt kernels. so each backported patch would now need to be applied to each of the kernels/branches, instead of just thrown into the appropriate generic folder Jan 08 11:41:31 I was thinking about something like this in the morngin: git reset --hard $upstream_version; git merge files-4.14; git merge generic-4.14; git merge hacks-4.14; git merge ath79-4.14 Jan 08 11:42:16 ynezz: you can't do hard resets in a shared git Jan 08 11:42:39 or rather no history rewriting Jan 08 11:43:48 no shared git, just use per target directory as it's done today with git reference repo Jan 08 11:49:12 I don't quite follow what you suggest. or did you mean git am files-4.14/* etc? Jan 08 11:57:41 I think (didn't tried that), that it should be possible to reconstruct the final kernel tree from several branches, by merging them in proper order as layers Jan 08 11:58:11 but where do these branches come from? Jan 08 11:58:38 from openwrt kernel repository Jan 08 11:59:42 what if the ath79-4.14 depends on modifications of generic-4.14? so ath79-4.14 needs to be already on top of generic-4.14 Jan 08 12:00:18 but that's how it's done today as well, right? Jan 08 12:01:58 sort of. with a git repo you essentially need the ath79-4.14 branch already have files-4.14, hacks-4.14 and generic-4.14 merged Jan 08 12:02:11 generic patches could go in the master branch Jan 08 12:02:32 KanjiMonster: yes, but that's cheap in git, isn't it? Jan 08 12:02:50 ynezz: it gets complicated if you cannot rebase Jan 08 12:03:52 well, good point, I haven't thought about it that far Jan 08 12:16:59 karlp: BTW it seems like patchwork has picked up that patch properly https://patchwork.ozlabs.org/patch/1021677/ Jan 08 12:17:36 just wondering if it's complete as I don't see those config options used anywhere Jan 08 12:47:00 ynezz: the problem I see with the git approach is that kernel patches are usually changing in openwrt. To maintain history and the ability to checkout old versions we would need a new branch for each modification, like ath79-4.14-, and that it's hard to maintain IMHO Jan 08 13:02:16 karlp: lol no Jan 08 14:03:27 luaraneda: yes, agree **** BEGIN LOGGING AT Tue Jan 08 19:32:36 2019 **** BEGIN LOGGING AT Tue Jan 08 20:53:40 2019 Jan 08 22:14:46 hmmm my unifi AP AC Pro just spontaneously rebooted :/ Jan 08 22:15:44 https://gist.github.com/3a13d65110b641bdabf67e44ed6ba2f1 Jan 08 22:28:20 that's qualcomm telling you they already have your money but want some more. Jan 08 22:28:39 >:-) Jan 08 22:29:45 well "data bus error" suggest hardware error I think Jan 08 22:29:57 :( Jan 08 22:34:35 some moron decided to link my vps to his domain names Jan 08 22:34:53 if it happens again I'll flash my previous image to be sure Jan 08 22:34:54 and i can't get a hold of him, nor can his provider Jan 08 22:35:01 Borromini: ah, fun Jan 08 22:35:07 yeah.... Jan 08 22:35:18 Borromini: host kiddiepr0n on his domains then 😂 Jan 08 22:35:21 seems iptables and blocking domain names isn't really something simple Jan 08 22:35:27 stintel: maybe i could. Jan 08 22:35:31 smart idea. Jan 08 22:35:40 i will put on some defacing website, who knows. Jan 08 22:35:52 stintel: data bus error can have multiple causes, personally I've seen it being caused by: power supply being bad (voltage for the CPU or RAM go too low), bad hardware (probably RAM or connection from the SoC to the RAM - like damaged PCB/soldering/...) and incorrect memory clock frequency/timings Jan 08 22:39:27 there was a major spike in CPU usage right before it happened Jan 08 22:41:10 stintel: could also be a software problem Jan 08 22:41:48 it just means that some acces to sume bus (memory, peripheral) failed Jan 08 22:41:57 and the CPU got an exception for that Jan 08 22:42:36 I see. so it could be due to say an ath10k firmware update too? Jan 08 22:43:43 if it can be a software problem I suspect either the mac80211 bump or the qca988x-ct firmware bump Jan 08 22:44:47 I do not think the ath10k FW causes such problems Jan 08 22:45:25 but but Jan 08 22:45:32 it is known to kill kittens Jan 08 22:46:18 well let's first see if it happens again or if it was due to a solar flare :) Jan 08 22:46:44 or nuclear fart Jan 08 22:47:06 hehe Jan 08 22:50:33 maybe one of those gravitational waves **** ENDING LOGGING AT Wed Jan 09 02:59:57 2019