**** BEGIN LOGGING AT Sat Mar 21 02:59:57 2020 Mar 21 04:31:08 build #122 of at91/sam9x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/at91%2Fsam9x/builds/122 Mar 21 10:49:27 f00b4r0: thank god porn is still available at full 8k quality eh?! :-) Mar 21 10:49:40 mangix: are you working on musl 1.2 inteagrtion? Mar 21 10:49:52 ldir: lol Mar 21 10:50:29 * f00b4r0 is trying to remember the most efficient way to prepare kernel patches within the openwrt build system. not very pr0n Mar 21 10:51:04 actually it's a bit annoying... my ISP appears to have sized its pipes correctly.... so why do I have to suffer because some other ISP has failed to do so. Mar 21 10:52:40 ah it was something along the lines of 'init a git repo under the build dir, hack kernel (making sure you don't do a clean), commit changes, git format-patch the result' Mar 21 10:52:58 ah rite Mar 21 10:53:03 * f00b4r0 does the dance Mar 21 10:53:31 making progress with my routerboot mtd handler. Although I don't have hardware to test it, so I'm going to have to rely on rpuyo :) Mar 21 10:54:08 (all my mikrotik gear is currently under heavy use and unplugging one would see me face dire consequences ;^) Mar 21 10:55:46 I have a pile of mikrotik stuff (hap lite, hap ac lite), don't hesitate to ask if you need help testing stuff Mar 21 10:56:03 hmm wait, does it need a serial console? :D Mar 21 10:57:49 f00b4r0: filed away under 'sensible kernel edit working.txt' & showing its age: [19:03:27] cd build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/linux-4.14.48/ Mar 21 10:57:49 [19:03:48] git init && git add -A && git commit -m "init" Mar 21 10:57:49 [19:03:53] edit files directly Mar 21 10:57:49 consider disable [*] Advanced configuration options (for developers) -> [ ] Automatic rebuild of packages Mar 21 11:02:14 ldir: thx! :) Mar 21 11:02:37 zorun: it probably shouldn't if you test via initramfs. Worst case, it just won't boot. Mar 21 11:02:46 zorun: and thanks, I will likely ping you later :) Mar 21 11:05:06 f00b4r0: ok, initramfs looks good :) I'm not moving anyway :D Mar 21 11:05:19 hehe Mar 21 11:08:13 oh dear. I'm trying to insert a patch to drivers/mtd/parsers/Makefile via target/linux/generic but there's another patch coming from target/linux/ath79 (which I'm building for) which also changes that file Mar 21 11:08:17 * f00b4r0 starts pulling hair Mar 21 11:11:07 * f00b4r0 has a feeling target/linux/ath79/patches-4.19/404-mtd-cybertan-trx-parser.patch doesn't belong there Mar 21 11:12:45 and it's not alone. *sigh* Mar 21 11:14:03 erm, 4.19 ? Mar 21 11:15:08 that's what it's using Mar 21 11:15:13 I'm on master Mar 21 11:19:57 5.4 is available as a TESTING_VERSION - I'd be tempted to look at 5.4 - it might actually make it easier Mar 21 11:20:36 I usually try not to change too many variables at once when testing new code :) Mar 21 11:21:26 true - but you'd have to forward port it then to 5.4 Mar 21 11:22:06 it's only the Kconfig/makefile bits Mar 21 11:22:12 the rest is a new file Mar 21 11:23:26 I'll shut up then :-) Mar 21 11:24:06 meanwhile it looks like i'll have to untangle another 4K_SECTORS SNAFU. It seems ath79 requires it to handle small mtd partitions, whereas it worked perfectly without on ar71xx Mar 21 11:37:24 Small writeable partitions? Do any vendors require that? Mar 21 11:39:09 mikrotik does Mar 21 11:39:30 the soft_config partition, which is edited via rbcfg, is 0x1000 long Mar 21 11:39:38 my only mikrotik device is NAND Mar 21 11:40:18 this posed no challenge on ar71xx but apparently on ath79 editing this partition alsoo trashes the previous one Mar 21 11:41:32 and if i recall my discussions with nbd correctly, there's no reason why it should. Maybe there's a regression in the code somewhere. Gotta check Mar 21 11:42:11 it's amazing how much time you have when you're confined and the weather is ugly. Day 5, still no zombies ;) Mar 21 11:50:14 f00b4r0: have you seen "my" mailing list thread where we discussed ath79 4k sectors? Apparently, enabling that will break some tplink boards. Mar 21 11:50:26 (but so far nobody complained...) Mar 21 11:50:51 PaulFertser: enabling it usually breaks upgrades and slows devices Mar 21 11:51:17 it should be avoided as much as possible. Or at least a sane LIMIT should be set (default to 4MB iirc) Mar 21 11:52:37 f00b4r0: the limit is already set, yes. Enabling it on my 4M device doesn't break anything, and there's no reason it should break upgrades on devices where OpenWrt build system knows if the target flash IC supports 4k or not. Mar 21 11:53:29 it used to break upgrades due to jffs2 aligments issues with the saved config Mar 21 11:53:50 f00b4r0: that's only in case where there's a mismatch between image makefile and reality. Mar 21 11:54:18 f00b4r0: the problem with some tplinks is that there're models which use both 4k-capable and incapable flash ICs. Mar 21 11:55:15 PaulFertser: I'm referring to: https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009863.html (and my proposal here https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009879.html) :) Mar 21 11:55:30 it's old. maybe it doesn't bite that much anymore. Mar 21 12:00:55 f00b4r0: nope, still the same Mar 21 12:01:01 heh Mar 21 12:01:17 i got zero reply to my RFC, so I let go of the idea. I liked it tho. Still do :) Mar 21 12:03:10 f00b4r0: https://lists.openwrt.org/pipermail/openwrt-devel/2019-December/020864.html Mar 21 12:03:29 f00b4r0: I see on the ML archive you got reply from Felix, so not exactly zero. Mar 21 12:06:01 it was a cliffhanger though :) Mar 21 12:07:07 Too bad gch981213 who mostly cares about tplink boards these days didn't reply at all. Mar 21 12:21:11 Do what I do, spend days right at the limit of your coding ability, send it upstream, who then say "can you make it do X, W, Y, Z oh and U as well", or "No" Mar 21 12:21:47 actually that's a bit unfair, I have actually got some changes into the kernel. Mar 21 12:23:13 the latest one though is iptables related and the response is basically "great, we need it in nftables as well and it has nothing like this, so if you could re-write the parser in nftables that'd dandy' Mar 21 12:23:49 * ldir just then looks blankly at the world...and even more blankly at nftables Mar 21 12:30:45 okay it builds. Now to ask a brave soul to test it Mar 21 13:21:58 build #242 of sunxi/cortexa8 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa8/builds/242 Mar 21 14:06:49 have you seen http://wiki.prplfoundation.org/ recently? :| Mar 21 14:07:03 Hauke: can you ping someone from prpl about that? Mar 21 14:22:11 Oooh candles! Mar 21 14:28:34 rmilecki: I will ask Mirko Mar 21 14:40:21 rmilecki: but are these nice candles? :3 Mar 21 14:51:35 * f00b4r0 wonders if https://git.openwrt.org/5cc0493c2bac committed by rmilecki could be the cause of small mtd write no longer working Mar 21 15:14:37 f00b4r0: it could not, we already had the same fix in our downstream patch Mar 21 15:15:30 rmilecki: what bugs me is the changes to 411-mtd-partial_eraseblock_write.patch Mar 21 15:16:13 based on the commit message I don't get why this patch is modified tbh Mar 21 15:16:16 f00b4r0: i basically extracted one line from 411-mtd-partial_eraseblock_write.patch and made it upstream patch Mar 21 15:16:44 so 411-mtd-partial_eraseblock_write.patch was modiifed as it doesn't modify that single line anymore Mar 21 15:17:02 reading diff of diff is always complex, try using some side by side comparision Mar 21 15:17:14 that it is ;) Mar 21 15:20:22 if amazon will still deliver to my place I guess I'll order some extra hardware to try to reproduce the issue locally. Easier to debug than asking over email ;P Mar 21 15:42:04 * f00b4r0 is endian-confused again Mar 21 15:42:16 ath79 is BE? Mar 21 15:42:35 f00b4r0: if you embed your SSH key in your image (and define a root password...), I can boot images and provide you with remote access Mar 21 15:42:56 0bf0r0b4 ? Mar 21 15:43:03 zorun: thanks! I might take you up on this Mar 21 15:43:56 or maybe r0b40bf0 ? Mar 21 15:44:29 i guess that Mar 21 15:46:21 do you already have an account on https://cfarm.tetaneutral.net/ ? simplest is, we pick a machine, you drop images in a folder I mount over sshfs and serve with TFTP Mar 21 15:50:46 I think I used to have an account but I doubt it's still active. I should ask guerby Mar 21 15:52:47 let me check Mar 21 15:52:58 zorun: login would be 'varenet' Mar 21 15:53:22 got it Mar 21 16:04:08 f00b4r0: yes, most MIPSes are big endian, but ramips/mediatek are little endian. Mar 21 16:04:38 f00b4r0: if the generated toolchain is "mipsel" then its little endian, if just mips, big. Mar 21 16:31:01 f00b4r0, hey :) long time no see/mail :) Mar 21 16:38:14 PaulFertser: thanks Mar 21 16:38:37 guerby: yeah, life has been pretty hectic for me these past few years :P Mar 21 16:38:55 guerby: hope you're doing all right in the current madness :) Mar 21 16:40:06 f00b4r0, well work from home so not so bad Mar 21 16:40:17 f00b4r0, hope you're ok too :) Mar 21 16:40:48 guerby: currently "on vacation", in Normandy, supposed to resume work remotely next week. Can't complain :) Mar 21 16:41:58 f00b4r0, ok :) Mar 21 16:42:10 * guerby going out for a walk + shopping Mar 21 16:42:11 bbl Mar 21 16:42:29 guerby: are you even allowed ;D Mar 21 17:38:29 rmilecki: 80-column is still a thing in new kernel code? (splitter is apparently working, cleaning up a bit now :) Mar 21 17:40:00 f00b4r0, still ok in Albi (81000), did not see a cop in a week while walking/shopping every day Mar 21 17:40:13 fun to see "Corona" beer in the supermarket Mar 21 17:40:49 guerby: sounds nice. Apparently cops are cracking down on Paris nowadays (according to family/friend there) Mar 21 17:41:37 f00b4r0, I walk only, friends have told me they've been checked by cops while in car Mar 21 17:42:40 I see. Because obviously one is a greater risk while in their cars than while walking ;P Mar 21 17:44:49 f00b4r0: IIRC checkpatch is unhappy about lines over 80 chars Mar 21 17:44:56 *sigh* Mar 21 17:45:17 f00b4r0, police seems to be targeting roundabouts here Mar 21 17:45:52 ldir: amazing how we're still stuck in teletype era in 2020 ;) Mar 21 17:46:23 guerby: probably applying the Law of Minimum Effort ;) Mar 21 17:46:34 f00b4r0, yeah Mar 21 19:57:11 morning/evening Mar 21 19:58:36 any objections to have unique profile names over targets? so when a generic profile is used for say x86/64, the profile would be called generic-x86_64 instead of just generic? Mar 21 20:22:08 f00b4r0: ./Documentation/process/4.Coding.rst Mar 21 20:35:40 rmilecki: close enough, I checked coding-style.rst ;P Mar 21 20:38:36 (which states 80-column is a "strongly preferred limit") Mar 21 20:39:21 rmilecki: the http://wiki.prplfoundation.org/ DNS entry is now removed Mar 21 20:39:46 the most intresting page is still in the wayback machine: https://web.archive.org/web/20180228015443/http://wiki.prplfoundation.org/wiki/MIPS_documentation Mar 21 20:44:41 Hauke: thanks Mar 21 20:48:51 rmilecki: I'm trying to insert the compilation bits for my parser (Kconfig/Makefile) in linux/generic, but some archs apparently also touch drivers/mtd/parsers: is this okay? I would expect that all files living under drivers/ would be handled by the generic target? Mar 21 20:56:27 aparcar: I do not see what the benefit would be, expect added complexity/possibility for mistakes Mar 21 21:01:21 f00b4r0: sounds good to me Mar 21 21:01:48 rmilecki: it's going to be difficult to do because of those other arch bits which trigger conflicts when I add mines Mar 21 21:02:16 generic is applied first afaict Mar 21 21:02:19 yes Mar 21 21:02:43 is the proper fix to move these other bits back in generic, or to update each patch so that "it works"? Mar 21 21:03:41 i'm not familiar with that target specific code Mar 21 21:03:48 if it's sth generic, we could move it to generic Mar 21 21:03:54 hacks should stay in targets probably Mar 21 21:04:08 your code is meant to be generic afariu, something to upstream at some pint Mar 21 21:04:14 so it sounds OK to put it in generic Mar 21 21:04:35 or maybe you can keep it in target until we upstream it and then with some kernel bump this problem will get solved Mar 21 21:04:48 i've spoted e.g. target/linux/ath79/patches-4.19/404-mtd-cybertan-trx-parser.patch Mar 21 21:05:01 imo this belongs in generic Mar 21 21:05:19 my code defiinitely belongs to generic because it will work for ath79, ramips and ipq Mar 21 21:07:42 it seems that parser_cybertan.c could deal with cybertan header and then let standard trx parser handle the rest Mar 21 21:07:50 right now it seems to partially duplicate trx parser Mar 21 21:10:21 adrianschmutzler: I thought it would be good to have a unique image identifier which could then also be stored on the running device. Mar 21 21:11:18 adrianschmutzler: you saw my ubnt_bullet-m-ar7240 patch v5? Mar 21 21:13:19 russell--: I just merged it Mar 21 21:14:14 aparcar: hmm, okay, so this is more aiming at the specific situation at x86 than at generic images in general Mar 21 21:14:56 adrianschmutzler: yes. So not for ath79. However there may be other targets which such generic images Mar 21 21:15:07 The pseudo default profile would stay untouched Mar 21 21:15:41 okay, then just ignore my comment, on x86 I'm not really qualified to judge Mar 21 21:16:19 though I wonder whether those generic profiles on targets like ath79 are actually used for anything or just remnants ... Mar 21 21:20:29 adrianschmutzler: ah nice, thanks! Mar 21 21:20:41 Do they exist for ath79? Mar 21 21:21:06 rmilecki: just in case you know off the top of your head: ofpart.c doesn't seem to have code to pull the node-name if neither "label" nor "name" properties are present, although the spec says the node-name should be used in that case. Mar 21 21:22:00 and I can't find code that would suggest this is handled elsewhere, would you know if I should deal with that case "by hand" in my code? Mar 21 21:22:02 I'm referring to the "Default profile" actually, so generic was not precisely correct: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/generic/profiles/00-default.mk Mar 21 21:22:19 (currently I am) Mar 21 21:25:44 adrianschmutzler: question about SUPPORTED_DEVICES, what is bullet-m going to match? Mar 21 21:25:56 the board name in ar71xx Mar 21 21:26:22 it's +=, so the current name is always included by Device/Default Mar 21 21:27:18 will it also match ar7241 devices before my previous renaming commit? Mar 21 21:30:19 no. I considered that and had a weak tendency against it, as iirc those devices would have had broken ethernet anyway? Mar 21 21:31:07 but it will match ar7240 devices coming from ar71xx of course Mar 21 21:31:42 I'm also not sure yet how this should be dealt with in 19.07 Mar 21 21:32:13 seems like it would be reasonable for a user to need to do a -F during sysupgrade Mar 21 21:32:15 I currently favor to just rename bullet to ar7241 there Mar 21 21:32:37 since there is no obvious automated way to get it right Mar 21 21:32:45 russell--: that's my point, yes. and it would prevent future users from accidentally crossflashing Mar 21 21:33:41 though I know there are different views among maintainers about when -F is appropriate Mar 21 21:35:57 i guess i'm suggesting that we don't automatically match bullet-m's coming from ar71xx Mar 21 21:36:58 ah, sorry, i didn't get that Mar 21 21:37:30 ar71xx has been working for both ar7240/ar7241? Mar 21 21:37:36 yes Mar 21 21:37:45 except for eth0 speed bugs Mar 21 21:38:00 since years Mar 21 21:38:11 than having SUPPORTED_DEVICES += bullet-m for both would be consistent with previous use Mar 21 21:38:14 which is part of my motivation to work on this ;-) Mar 21 21:38:34 e.g. wdr3600/wdr4300/wdr4310 all having wdr4300 board Mar 21 21:38:54 (though those wouldn't break if wrong image was flashed) Mar 21 21:39:03 right Mar 21 21:40:12 but since we have precise names in master now, I wouldn't remove the bullet-m there Mar 21 21:40:36 i'm thinking that needing the -F would be the warning to users that some-thought-required-here Mar 21 21:40:57 hmm, I see your point. Mar 21 21:41:09 just thinking whether it's strong enough for me ... Mar 21 21:42:48 f00b4r0: i don't know Mar 21 21:43:11 rmilecki: ok thanks. I have worked around the build bits Mar 21 21:43:19 To be honest, I'm 50:50. So if you would provide a patch to remove SUPPORTED_DEVICES for both, I'd accept it if nobody objects (= as so far). Mar 21 21:44:28 and how would you deal with 19.07? Mar 22 01:55:54 building master for alix2 results in no errors and no image Mar 22 01:58:04 oh, weird. squashfs image was de-selected. Mar 22 02:12:23 bash: *1024*1024: syntax error: operand expected (error token is "*1024*1024") Mar 22 02:18:21 tig Mar 22 02:21:27 maybe CONFIG_TARGET_ROOTFS_PARTSIZE undefined? Mar 22 02:34:23 starting from a dirclean Mar 22 02:47:48 anyone know how to check ath10k temperature? Mar 22 02:54:30 aparcar[m]: broken x86 ^^^^^ **** ENDING LOGGING AT Sun Mar 22 02:59:58 2020