**** BEGIN LOGGING AT Tue Jul 30 03:01:12 2019 Jul 30 03:19:18 DonkeyHotei: That's almost fair, but there are also Ath79-only targets Jul 30 03:19:39 sadly yes Jul 30 03:20:03 i know because i added one or two myself Jul 30 03:20:14 Lol Jul 30 03:20:54 Doesn't affect me because the devices I add are not yet mainlined Jul 30 03:21:05 but still, I was interested. Jul 30 03:32:33 DonkeyHotei: can you help explain the "missing alias section"? Jul 30 03:37:55 ssn: take a look at target/linux/ath79/dts/qca9561_tplink_archer-c6x.dtsi to compare Jul 30 07:02:53 DonkeyHotei: will do Jul 30 07:02:59 thanks Jul 30 07:03:09 yw Jul 30 07:08:13 blogic: sorry about that, should I revert that commit now? Jul 30 07:11:48 blogic: ah, you've fixed that already, thanks Jul 30 07:13:08 and you're missing the commit description, probably making a lot of pedantic people angry now :) Jul 30 07:13:28 missing Fixes: tag... Jul 30 07:13:30 * ynezz hides Jul 30 07:13:39 plenty of other commits miss a description Jul 30 07:13:58 ynezz: :-) Jul 30 07:14:18 i am more worried about the code Jul 30 07:15:33 yeah, I've just missed that indent change, anyway still wondering where is the Makefile coding style guide :-) Jul 30 07:16:05 so I can point people to this nice reading next time I spot some issue Jul 30 07:19:28 the code is Jul 30 07:48:09 * ldir blogic appears to have dropped out mid sentence Jul 30 08:04:42 * ldir ponders if he meant 'the code is the documentation' Jul 30 08:07:43 looks like I've actually got a build out after the python/wireless-db fiasco - that's involved a dirclean Jul 30 08:09:35 dammit spoke to soon Jul 30 08:14:00 ldir: :-) Jul 30 08:14:05 ah, my mistake Jul 30 08:17:23 morning Jul 30 08:17:28 are we bikesheding? Jul 30 08:22:09 we've moved on from the colour and are now on how spacious (some might say tabious) it should be ;-) Jul 30 08:22:09 jow: nope Jul 30 08:22:25 jow: that would be discussing it, i simply fixed it Jul 30 08:25:35 fixing it? Outrageous! I think we should discuss the minutia of spacing or whether certain lines should be above or below other lines and ignore the fact a package bump has some security fixes in it. Oh my mistake that *is* done already /s Jul 30 08:29:58 yay - build finished! Jul 30 08:42:20 ldir: I think ti should have been a github pul lrequest Jul 30 08:45:22 Well I've just joined the wireless-db commit party Jul 30 08:46:14 ldir: wrong door then this is the wireless-regdb one, sorry Jul 30 08:46:49 lol - thank goodness I got the commit title correct Jul 30 08:47:21 ldir: you ate my breakfast clown Jul 30 08:47:35 one patch - and it had fuzz - shakes head Jul 30 08:48:01 and the wrong door Jul 30 08:48:03 is there a linting tool for device tree files? Jul 30 08:48:27 aparcar[m]: not the last time i checked Jul 30 08:49:03 blogic: so it is not astyle or something compatible? Jul 30 08:50:31 aparcar[m]: you could first compile to dtb, then convert back to dts (dtc can do both directions) - you'd loose the comments though ;D Jul 30 08:50:56 (obviously won't work with includes and stuff) Jul 30 09:09:15 aparcar[m]: https://github.com/devicetree-org/dt-schema/ Jul 30 09:20:02 aparcar[m]: ah, you were looking at linting tool, sorry :) Jul 30 09:54:11 jow: blogic: KanjiMonster: ynezz: does anyone have objections against patches which remove kernel 4.14 support in Master for targets which are already running 4.19 today? The leftover 4.14 files interfere with kernel bumping sometimes .. Jul 30 09:55:02 xback: not me Jul 30 09:55:24 fine by me Jul 30 10:00:30 AFAIR, they were left there for easier regression confirmation/testing in 4.19 (so you could just easily build 4.14 and compare the results with 4.19), but I understand, that it makes no sense to keep it if it means much additional work, so it's fine with me, you can add my Acked-by if you want Jul 30 10:01:19 or maybe just keep the patches there and don't rebase them during bumps Jul 30 10:02:08 but they're still in Git right, so if someone is interested in 4.14 testing, it could be reverted Jul 30 10:02:25 ynezz: the issue is that during a refresh, sometimes the script takes the wrong kernel Jul 30 10:02:41 while refreshing 4.19 for example .. it tries to apply the 4.19 patches to the 4.14 kernel etc Jul 30 10:02:43 or vice versa Jul 30 10:02:53 then fix the script :) Jul 30 10:03:02 huh, how does that happen? Jul 30 10:03:07 Agreed the refresh script should probably be fixed also Jul 30 10:04:21 KanjiMonster: the script searches for patches-* Jul 30 10:04:27 which can be 4.14 or 4.19 Jul 30 10:04:56 the script should also be fixed to not search generically, but also add the kernel version to the folder check Jul 30 10:05:17 which script? Jul 30 10:05:49 https://git.openwrt.org/?p=maintainer-tools.git;a=tree Jul 30 10:05:51 update_kernel.sh Jul 30 10:06:15 I encountered the issue again yesterday during 4.14 bumping Jul 30 10:07:01 In each target makefile, the kernel to be used is set Jul 30 10:07:08 it never checks for patches-*, only for patches- Jul 30 10:07:33 well yeah, that's what I mean :) Jul 30 10:07:45 the assumption is that if patches- exists, then is a valid, usable kernel version Jul 30 10:07:46 but when actually refreshing, it uses the value from Makefile Jul 30 10:08:07 so it sees : ooh, I found a patches-4.14, let's refresh Jul 30 10:08:17 that's why it passes KERNEL_PATCHVER=${KERNEL} LINUX_VERSION=${PATCHVER} to refresh, to override the value from the Makefile Jul 30 10:08:21 when that happens, the refresh uses 4.19 as mentioned in the Makefile Jul 30 10:08:33 looks like it gets ignored? Jul 30 10:08:39 You can easily test it Jul 30 10:08:43 just checkout current master Jul 30 10:08:47 and try to bump 4.14 Jul 30 10:08:56 maybe this got broken with the testing kernel support? Jul 30 10:09:06 was my hunch as well just now Jul 30 10:09:12 it also had the same behaviour before that got applied by nbd Jul 30 10:10:13 when doing the test above, it will fail pretty quickly Jul 30 10:10:27 then running make target/linux/{clean,prepare} V=s QUILT=1 Jul 30 10:10:36 will show that it unpacked kernel 4.19 iso 4.14 Jul 30 10:10:49 and the 4.14 patches wont apply, which is the reason for the fail Jul 30 10:12:57 sounds like a bug in openwrt Jul 30 10:13:07 that cannot be Jul 30 10:15:50 so we now require both python2 and 3(.5)? "Checking 'python2-cleanup'... ok." "Checking 'python3'... ok." Jul 30 10:22:09 so guys - sorry for the unusual request. Since I am blind, soldering UART cables and things like that can be an issue. can someone of you help me out ? I may send some of my devices / pay all expenses and so on... Jul 30 10:22:34 I also would need help in programming flash of an MR200 - I know it doesn't need to be de-soldered but I don't have an easy way to set up things on my own Jul 30 10:29:14 xback: do you have a concrete target where it fails? I just tried brcm47xx refreshing 4.19, and refresh 4.14 with kernel set to 4.19 in the Makefile, and both worked fine Jul 30 10:29:44 KanjiMonster: re-reading my story above shows the issue i guess .. Jul 30 10:31:21 running make target/linux/{clean,prepare} V=s QUILT=1 should also contain KERNEL_PATCHVER= and LINUX_VERSION= ....... or it will take the value from Makefile :p Jul 30 10:31:45 yes, thats what I did Jul 30 10:32:25 make target/linux/prepare V=s KERNEL_PATCHVER=4.14 LINUX_VERSION=4.14.132 (with target/linux/brcm47xx/Makefile:KERNEL_PATCHVER:=4.19) Jul 30 10:32:36 and the other way round Jul 30 10:32:41 and that's what i did not ;p Jul 30 10:33:10 but that is what the update_kernel.sh script does Jul 30 10:33:43 yeah, until a patch does not apply, at which point the manual command above is needed Jul 30 10:34:09 and where I was missing the overrides Jul 30 10:34:13 maybe skip the prepare and just do a clean? Jul 30 10:46:11 xback: I still don't quite understand where exactly it fails for you Jul 30 10:49:15 KanjiMonster: I'm using a 1 line script which just contains the manual line above Jul 30 10:49:38 it had a typo in the expansion of KERNEL_PATCHVER= and LINUX_VERSION= Jul 30 10:49:49 so it was simply not added in the resulting line ;-) Jul 30 10:50:38 the script avoids to retype the manual "make prepare" command over and over on refresh and patch alteration Jul 30 10:53:45 ... so the issue wasn't in refresh_kernel.sh or openwrt, but in your script? Jul 30 10:54:03 or rather what triggers the issue Jul 30 11:08:25 KanjiMonster: yes :$ Jul 30 11:10:37 xback: if you can condense it to a small order of openwrt make invocations with which to reproduce it, we can try to determine where it's breaking and fix it (in theory there should be no order of make invocations that should break the build, but in practice ... ;) Jul 30 11:12:06 I also noticed this in 19.07 when exiting menuconfig: https://pastebin.com/hVuqq8RE Jul 30 11:55:47 ynezz: do we really don't want ath79 for 19.07? Jul 30 11:55:58 i thought 19.07 was meant to provide both ar71xx AND ath79 Jul 30 11:56:05 with dropping ar71xx afterwards Jul 30 11:58:12 did I miss some discussion on *not* including ath79 in 19.07? Jul 30 11:58:23 Hauke blogic jow? Jul 30 12:00:00 Will there be more details about the upcoming release of 19.07? I am asking because August is coming. Jul 30 12:19:49 solved Jul 30 12:21:15 solved how? Jul 30 12:23:42 rmilecki: I vaguelly recall the plan to not have ath79 in 19.07 Jul 30 12:24:35 rmilecki: overall I'm neutral - but I believe/fear that ath79 in 19.07 will devolve into a not relaly finished, too early to release target since device support will get pushed to master and never backported Jul 30 12:25:01 especially since the more complex boards require new dts or userspace facilities which likely will not get backported either Jul 30 12:33:28 ynezz: did you see that https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=a1c6a316d2997b6bbee520fb1bf21f3b994f9e52 breaks the wzr-hp-g300nh ? Jul 30 12:44:59 jow: ynezz: this probably (potentially) broke every device using any of the uimage parsers, except the newly added one - extralen is never initialized for all the other parser variants, so contains a random stack value, which then triggers "if ((offset + uimage_size) > master->size) {", if the stack value is larger than the mtd size Jul 30 12:49:30 jow: nope, I'm not aware about that, where is the bug reported? Jul 30 12:51:56 KanjiMonster: so you think, that `int extralen = 0;` would fix this? Jul 30 12:52:03 yes Jul 30 12:52:17 I've boot tested it on my mt7620 device, so I was probably lucky Jul 30 12:53:43 jow: FS#2413 got it Jul 30 12:57:43 rmilecki: AFAIR there was no plan to have both ar71xx/ath79 in the stable release, so that's why I've disabled ath79, if I'm mistaken, please point me to the discussion, where it was decided Jul 30 12:59:39 rmilecki: that's why I didn't even bothered to send this patch to the mailing list for review/comments as I simply took it as a fact, that 19.07 is having ar71xx only and ath79 is going to be in next release Jul 30 13:10:33 rmilecki: personally I'm afraid, that we'll just get more bug reports nobody is going to take care about, as once there are images available in the release, I think, that it should be supported Jul 30 13:11:51 rmilecki: so in the end it might boil down to "use latest snapshot image for ath79 as the problem was fixed in 4.19 kernel, but we can't backport it easily to 19.07/4.14 unless backporting half of the universe as well" Jul 30 13:12:44 4.14 fixes a lot over 4.9 though Jul 30 13:14:30 well, this is what I'm doing today, if someone reports issue in 18.06 I'm usually just saying "please test it with the latest snapshot images, it should be fixed there" Jul 30 13:16:36 providing images is no brainer for me, support is another matter (I know, we do badly with ar71xx support anyway, but that's another story) Jul 30 13:19:14 anyway, rc1 is not out yet, so there's still some time to discuss this :) Jul 30 13:24:59 KanjiMonster: it seems like extralen is set to 0 here https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c;h=091403ae9186baa1827e942bf3948783aba04a4f;hb=HEAD#l124 Jul 30 13:26:38 ynezz: oh, indeed, I missed that line Jul 30 14:37:22 ping jow - did you make any more progress re: the packages selection issue in addition to the 'hacky' workaround ? Jul 30 14:38:08 jow: would you consider the 'hacky' workaround of sufficient 'quality' to be committed? Jul 30 14:39:34 I'm happy the it solves the selection problem I fell into yesterday, and I've nearly completed testing for dropping the base cake package again, replacing with an out of tree equivalent. Jul 30 14:40:27 ie. you can't select 'in tree' cake on ldir: I cannot judge potential side effects Jul 30 14:44:35 ldir: didn't make much progress today with this issue Jul 30 15:08:12 no problemo Jul 30 15:58:10 jow ynezz could you please comment on this PR https://github.com/openwrt/openwrt/pull/2250 Jul 30 15:59:41 woudl have been easier to maintain alternates if you hadn't split the name up tinto little pieces :) Jul 30 16:02:07 sorry I don't get your point. Aren't these two independtent and usefull features? Jul 30 16:02:44 *independent Jul 30 16:05:49 anyone familiar with nand devices? https://github.com/openwrt/openwrt/pull/2194#issuecomment-516422736 Jul 30 16:24:35 angelsl: i was not aware of that patch and have now written a competing one Jul 30 16:25:11 DonkeyHotei: your device uses a nand with dualboot too? Jul 30 16:25:19 nor Jul 30 16:27:07 i suppose it would be nice Jul 30 16:27:13 then we don't have to hardcode kernel sizes Jul 30 16:27:25 it'll help quite a few devices Jul 30 16:28:29 but it has two prerequisite patches i am hoping can be slated for mainline first Jul 30 16:30:09 what are they? Jul 30 16:31:56 anyway, that doesn't answer my main question of - did those other devices just ignore the possibility of a bad eraseblock, or is there something i'm missing here Jul 30 16:32:08 idk Jul 30 16:33:48 there's this issue also which.. might be relevant: https://bugs.openwrt.org/index.php?do=details&task_id=1926 Jul 30 17:07:41 is there a make target to just rebuild a DTS and repackage an initramfs image? Jul 30 17:07:56 right now, when I edit a DTS and run make, it seems that the build system rebuilds the whole kernel Jul 30 17:08:34 it makes the edit-compile-boot cycle quite cumbersome when developing Jul 30 17:10:40 rmilecki: I also think we wnated to provide ar71xx and ath79 in 19.07 Jul 30 17:10:49 I see jobs like "make -f ./scripts/Makefile.build obj=fs need-builtin=1" during the "-C target/linux install" phase Jul 30 17:11:01 not sure if it is expected that the kernel gets rebuilt at this point Jul 30 17:22:40 huh, brcm47xx doesn't seem to have DTS files Jul 30 17:38:50 mangix: yes brcm47xx is old and does not ue dts Jul 30 18:17:14 Hello OpenWrt devs, I sent a small RFC last week https://patchwork.ozlabs.org/patch/1137710/, I don't know if @nbd is around (I'm patching one of his hack) else if anybody can give feedback that would be much appreciated Jul 30 20:10:35 would anybody have an example of ath10k calibration data for ipq4018/ipq4019? Jul 30 20:12:18 it should be readable from /lib/firmware/ath10k/pre-cal-ahb-a000000.wifi.bin and /lib/firmware/ath10k/pre-cal-ahb-a800000.wifi.bin Jul 30 20:13:24 if anybody runs on the models in https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata#L186 :) Jul 30 20:33:08 zorun: i vaguely remember that those files are populated from eeprom or flash if they don't exist Jul 30 20:35:33 jow: do we have reources to build ath79 for 19.07 ? Jul 30 20:36:47 imho the ppl using owrt are the actual owners. the thread shows that they really want it. Jul 30 20:37:11 i see no reason but cpu power to not build it ans just note it in the release notes as WIP Jul 30 20:37:28 if its a cpu power issue, I am happy to chip in a server Jul 30 20:38:03 and then we can clearly mark ar71xx as EOL and say that 19.07+1 is the last release where we build ar71xx and users should help upgrade and/or similar Jul 30 20:38:31 russell--: yes, exactly, but apparently mikrotik decided to compress that using a custom algorithm Jul 30 20:38:38 name the ath79 related folder as ath79-beta or something? assuming it is considered such Jul 30 20:38:44 which is why I would like an example of how it looks like uncompressed :) Jul 30 20:39:10 olmari: good idea, but would require a hack as opkg looks for ath79 Jul 30 20:39:25 the joys of implicit logic in the code :-) Jul 30 20:39:42 mm well... just an idea =) Jul 30 20:39:52 release notes should be enough Jul 30 20:40:03 this is the sort of thing that people tend to read for major releases Jul 30 20:40:10 (well, let's hope :p) Jul 30 20:40:37 blogic: couldn't we just make any ath79/*/packages still be available (through rewrite rules or just hiding the toplevel ath79 folder)? Jul 30 20:40:43 and large enough mention on any blog/page/whatever post immediately relatingto 19.07 release (in general) Jul 30 20:42:09 KanjiMonster: up to jow really but rewrite would be an option did not think about that Jul 30 20:46:31 wasn't osuosl offering build resources? Jul 30 20:55:14 I seem to recall discussions from about a month ago about regressions and instability in ath79 relative to ar71xx. I don't have chat logs but wonder if that's why ath79 was disabled. Jul 30 20:55:45 i thought those were addressed Jul 30 20:56:10 ah, I probably missed that due to vacation. Jul 30 20:56:44 what I'm vaguely recalling may be also related to 4.19 vs 4.14 stability. Jul 30 21:11:07 ok, I got hold of some ath10k caldata for ipq4019 :) Jul 30 21:31:51 zorun: remind me what model that was? Jul 30 21:33:05 russell--: the one we were hacking at battlemesh? mikrotik hAP acĀ² Jul 30 21:35:59 zorun: /me is trying to figure out which specific model, in case he weakens and decides to buy one to play along Jul 30 21:39:48 https://mikrotik.com/product/hap_ac2 Jul 30 21:49:07 RBD52G-5HacD2HnD-TC Jul 30 21:49:26 yes, that's the one Jul 30 21:50:44 (both links/names) Jul 30 21:51:34 * russell-- assumes that model name is a cryptographic hash of some kind Jul 30 21:53:21 :D Jul 30 21:53:43 mikrotik actually manages a 1:1 description of the hardware in the name of the devices Jul 30 21:53:46 quite a feat Jul 31 01:10:37 rmilecki: when did this DEFAULT_VARIANT come in? Jul 31 01:11:22 varient isn't even covered on https://openwrt.org/docs/guide-developer/packages guess i can't be irritated by DEFAULT_VARIANT not existing either **** ENDING LOGGING AT Wed Jul 31 02:59:56 2019