**** BEGIN LOGGING AT Fri May 08 02:59:59 2020 May 08 06:29:38 gch981213: any idea about https://github.com/openwrt/openwrt/pull/2526 ? May 08 08:24:34 looking at https://sources.cdn.openwrt.org , there are some questionable filenames there May 08 08:30:10 you can reproduce that locally if you enable CONFIG_DOWNLOAD_FOLDER - there is no prefix when saving a file from some sources May 08 08:30:38 no i mean some of the files are reallt old May 08 08:32:32 probably because some sources do not provide their old source code packages and recompiling software for older openwrt releases might fail then? May 08 08:33:35 not sure what exactly the policy is - but not every developer wants to dig through internet archive or monitor the _historic_ availability of source code May 08 08:36:42 i have ~37g "random" source files from packages feeds etc. so i *should* be able to more or less test build full package feeds even when offline May 08 09:04:52 i've noticed even a 'make download' prior to compiling won't pull in everything you need. May 08 09:05:35 when i switch my desktop to a test router (not on the internet) the build will just sit because curl is still needing some files, in the middle of the make run >_> May 08 09:20:13 nitroshift: ping May 08 09:20:20 stintel, pong May 08 09:20:39 so about that macchiatobin :) May 08 09:20:54 right May 08 09:21:05 getting on it :) May 08 09:21:54 cheers May 08 09:22:09 it's the doubleshot, correct? May 08 09:22:24 yes May 08 11:13:57 Hi, using imagebuilder snapshot to build a custom router is not very stable, right? May 08 11:14:05 I have dependency errors May 08 11:15:57 looks like https://github.com/openwrt/luci/issues/3079 May 08 14:00:20 i'm seeing kernel patch errors with the last routerboot commits May 08 14:00:43 clean build :) May 08 14:01:43 https://paste.debian.net/1145722/ May 08 14:02:46 hmm, maybe it wasn't rebased on the tplinkparser move/deletion? May 08 14:02:49 i'm forgetting thibaut's irc handle May 08 14:03:21 nonsense, that's still generic May 08 14:07:41 it's not rebased on the myloader changes. May 08 14:08:14 https://github.com/openwrt/openwrt/commit/5f923498415d79dc500f7ba26c30dde5c9f27586 May 08 14:08:18 that one May 08 14:08:57 will definitely affect 5.4 (as what you observe), not sure whether it will affect 4.19/4.14 May 08 14:16:26 build #26 of rockchip/armv8 is complete: Failure [failed toolchain] Build details are at http://buildbot.openwrt.org/master/images/builders/rockchip%2Farmv8/builds/26 blamelist: Rosen Penev , Jason A. Donenfeld , Petr ?tetiar , Stijn Tintel , Thibaut VAR?NE , May 08 14:16:27 Daniel A. Maierhofer , Jo-Philipp Wich , Yangbo Lu May 08 14:17:28 there it is i reckon :P May 08 14:18:51 failed on toolchain May 08 14:19:18 same here: time: toolchain/kernel-headers/compile#7.06#4.03#7.99 May 08 14:19:24 (i'm timing my builds) May 08 14:44:31 f00b4r0: Your routerboard parser patch just merged isn't rebased on my myloader patch May 08 14:45:15 this breaks build for 5.4 for sure. May 08 14:45:30 should be easy to fix though May 08 14:46:54 Borromini: I'm going through the other patches, and then will try to refresh patches unless somebody volunteers before that May 08 14:48:32 fixed locally on 5.4. testing it May 08 14:49:15 xback: thanks. should be relatively trivial, I hope May 08 14:49:35 yeah it was trivial May 08 14:50:35 will push a fix within 10 minutes or so. compile-testing running May 08 14:50:48 srry for the noise May 08 14:51:16 well, these things just happen when PRs are lying around for months May 08 14:52:23 do you plan to backport before/after 19.07.3? (i think you already stated that you want to target 19.07?) May 08 14:52:44 cool thanks xback May 08 15:01:42 adrianschmutzler: it will only be backported very partially, but not for .3 May 08 15:01:59 We will skip this to avoid rush-jobs on a stable May 08 15:02:09 r2 support will be for .4 May 08 15:02:57 the plan is to apply to ar71xx with minimal changes to stable May 08 15:05:55 Borromini: no thanks required.. cleaning up my own mess (again) :-) May 08 15:06:48 and mt7621 on 19.07? May 08 15:07:23 Does anyone happen to know what the 'P38' bit of 'ACME certsP38' means? May 08 15:07:34 fix pushed for the build error May 08 15:08:03 adrianschmutzler: that target is out of my scope, but I dont think any changes will be done to it. at least not from Thibaut or me May 08 15:08:04 When luci-app-acme got moved from packages to luci it seems to have gain 'p38' and I'm well, confused. May 08 15:09:19 xback: just went through the patches again, rest looks fine as far as I can tell May 08 15:10:17 mt7621 then essentially will continue to have the problems that are supposed to be fixed May 08 15:11:02 Thibaut already made a draft patchset for 19.07, but it still contains a compile-error May 08 15:11:13 I wonder whether it wouldn't be better to just backport the whole thing to 19.07, particularly if it's not rushed May 08 15:11:14 I guess it should be fixed over the weekend, but then testing is needed May 08 15:11:16 it should be fixed now May 08 15:11:20 so depending on release date of .3 May 08 15:11:31 it could be in .. maybe yes, maybe not May 08 15:11:49 I can only test further on Monday on Mikrotik targets May 08 15:11:52 won't need any of the ath79 changes in 19.07 May 08 15:11:55 divergence kept to an absolute minimum May 08 15:12:09 f00b4r0: link? May 08 15:12:18 adrianschmutzler: https://github.com/f00b4r0/openwrt/commits/rb1907 May 08 15:12:30 only the last 2 commits diverge from a pure backport May 08 15:12:36 I got buzzed directly about https://github.com/sean-m-miller/OpenWrt-LEDE-patches/blob/master/sysupgrade_ram_overlay_when_preserving_config/README.md - does it make sense to anyone? May 08 15:13:35 I'm not going to touch it because I'm very, very, very wary of rabbit holes and I've enough issues of my own to deal with. May 08 15:13:56 https://forum.openwrt.org/t/error-in-preinit-documentation-regarding-overlays/60188/3 May 08 15:14:19 I haven't looked if there's a flyspray entry about it. May 08 15:14:22 and the last patch in the series is in fact purely cosmetic. May 08 15:14:39 (I'll have to run soon) May 08 15:14:51 * ldir watches f00b4r0 apply eyeliner ;-) May 08 15:15:00 8) May 08 15:15:04 I'm off, already late again. Thanks f00b4r0, will give it a spin on monday May 08 15:15:12 xback: np yw May 08 15:15:16 thanks for handling this May 08 15:16:19 looks good. And I don't see a reason to not include mt7621 there as well May 08 15:16:59 mt7621 doesn't have wireless, so there is no (reported/known) breakage there atm May 08 15:17:29 but it's really up to ;) May 08 15:17:45 it boils down to the MAC addresses, where I seem to be one of the few caring May 08 15:18:05 I didn't bother backporting the mtd parser either. May 08 15:18:22 mt7621 seems to be "fine" with everything set in stone. At least for now. May 08 15:18:48 which device was the one where the changed offset was encountered May 08 15:18:55 you linked the comment somewhere May 08 15:18:59 my reasoning being "if it ain't broke don't fix it" May 08 15:19:14 it's an ath79 device May 08 15:19:16 lemme find it May 08 15:19:44 got it May 08 15:19:55 rb493g May 08 15:19:58 that one May 08 15:20:15 it's correctly covered by the existing ar71xx code. May 08 15:20:51 FYI there's at least my PR to close and maybe some of the PRs I linked in it which are superseded/obsoleted by the merged code. May 08 15:21:05 okay, then I'm also fine with not touching mt7621 May 08 15:21:10 good :) May 08 15:21:56 as it will be (though not much) additional work backporting it due to the recent changes there ... May 08 15:22:08 *nod* May 08 15:22:22 and as I pointed out, we wouldn't be "fixing" anything currently broken. May 08 15:22:33 contrary to ar71xx where some supported devices no longer work. May 08 15:22:47 but it's still an assumption that all mt7621 really have the same offset May 08 15:22:52 indeed. May 08 15:23:00 for partitions and MAC address inside partitions May 08 15:23:15 maybe by the time this assumption proves to be wrong, 20.x will be long out May 08 15:23:29 and if not it will always be possible to consider a backport _then_ May 08 15:23:38 Hello there, some of you have news about a new release of openwrt? May 08 15:23:40 and to properly fix that, we would need to backport the whole thing, including the second patchset May 08 15:23:45 yes May 08 15:23:52 more invasive to 19.07 May 08 15:23:58 hence me not being very hot on that. May 08 15:24:09 but really, not my call. May 08 15:24:32 anyway, i have to go now, bbl. May 08 15:24:33 I don't think the invasiveness would be that much of a problem. more the additional work which you judged to be not necessary. May 08 15:24:50 bye then. thanks for the discussion. May 08 15:24:54 np, yw May 08 15:26:09 how would I mark the patches in patchwork now: accepted or superseded (as some got modified in the Pull Request after that)? May 08 15:26:22 or does nobody care anyway? May 08 15:27:14 any common/best practices? May 08 15:50:24 no opinions? then I'll use "accepted" May 08 16:47:14 adrianschmutzler: accepted would fit best imho May 08 16:53:34 ldir: what is "p38" ? May 08 16:54:18 that's what I want to know. May 08 16:57:25 ldir: I eman, more like.. context :) May 08 17:19:54 jow: https://github.com/openwrt/luci/commit/076d93318729567cac1153e3645a18034a320079 May 08 17:27:09 ldir: ah, now I get it :) Smells like a fat finger bug to me May 08 17:29:54 BCP38 ???? May 08 17:30:21 yeah, maybe it was copy-pasted from there and then incorrectly changed or something May 08 18:08:04 w/c May 08 18:56:06 * Slimey secret of the ooze May 08 19:07:29 * stintel toasts to the demise of samba36 May 08 19:12:12 lol May 08 19:17:39 ldir: thanks for the p38 fix May 08 19:43:09 why does dnsmasq got `x` instead of `*` in the shadowfile? May 08 19:51:14 anyone else seeing segfaults from block? block[4217]: segfault at 84 ip 00005595dfe0f5ec sp 00007ffe6c6cc580 error 4 in block[5595dfe0f000+4000] May 08 19:52:47 https://paste.debian.net/1145693 <- here block also segfaulted May 08 19:54:15 ynezz: btw I picked up an old PR to make openwrt an official Docker image, have a look here if you care https://github.com/docker-library/official-images/pull/7975 May 08 20:15:50 adrianschmutzler: I gave a very quick review to #2796 and TBH I don't like what I see. It looks like ar71xx code is bluntly copy-pasted without much concern for making it behave well with OF primitives. I'm afraid this is an easy temptation for people who just want their hardware to boot, but IMHO not a desirable path May 08 20:16:48 (this matches my impression that ath79 needs a lot more plumbing before mikrotik devices can be _cleanly_ ported to the new target) May 08 21:14:11 stintel: cheers May 08 21:15:07 ksmbd may not be perfect, but it's at least faster and doesn't crash as ofter May 08 21:15:12 *often May 08 21:15:51 Well, upstream is running it through xfstests so that's something :) May 08 21:22:23 jow: any opinion on https://github.com/openwrt/packages/pull/11981 May 08 22:24:26 f00b4r0: thanks for your opinion, that at least partially matches my initial feeling about this May 09 00:19:00 does neheb hang out here? May 09 00:23:17 philipp64: they're "mangix" here. May 09 00:23:20 and yes. May 09 00:25:44 ah… never made that connection. May 09 00:26:17 mangix: seeing weirdness related to PR #11981. May 09 00:49:53 it hasn't been merged? May 09 00:49:57 are you just testing it? May 09 00:56:22 Has not been merged, no. I was just reviewing it. May 09 01:40:32 Does anyone have ideas how to enable crash log support on kernel 5.4? **** ENDING LOGGING AT Sat May 09 02:59:58 2020