**** BEGIN LOGGING AT Fri Jul 26 02:59:59 2019 Jul 26 06:17:22 Hi Jul 26 06:17:33 Anyone awake already and willing to merge this? Jul 26 06:17:36 https://patchwork.ozlabs.org/patch/1137192/ Jul 26 06:18:57 please be patient Jul 26 06:19:10 europe is just waking up, and the usa is just going to sleep Jul 26 06:19:32 well, this patch was send today, so I quite don't understand, what's the rush here Jul 26 06:19:45 well no, it has been in the works for a long time Jul 26 06:19:52 but yes, I'll be patient ;-) Jul 26 06:19:55 if I'm not mistaken, this device is supported in ar71xx already Jul 26 06:20:00 yep Jul 26 06:20:03 your are correct Jul 26 06:20:15 stuck on kernel 4.9 Jul 26 06:20:39 there are snapshot images for ar71xx as well Jul 26 06:20:57 and you can test 19.07-SNAPSHOT images as well, which should have 4.14 kernel Jul 26 06:21:04 ar71xx is not generating snapshots anymore Jul 26 06:21:23 but the older images are still there Jul 26 06:21:25 https://downloads.openwrt.org/releases/19.07-SNAPSHOT/targets/ar71xx/generic/ Jul 26 06:21:47 ynezz: you are making my case for me here. ar71xx is dead Jul 26 06:26:12 indeed, but it doesn't mean, that ath79 patches have higher priority, different treatment or stuff like that Jul 26 06:27:01 hm, sounds like they should though Jul 26 06:27:06 vendor-supplied patches... Jul 26 06:27:19 Shouldn't you encourage that? Jul 26 06:27:27 Vendors putting in the work and all? Jul 26 06:29:01 I see it as valuable contribution to the project, I pretty much don't care if it was done by Bob or Petr Jul 26 06:29:24 heh Jul 26 07:05:40 ssn: you send updated versions of your patch without any versioning and without replying to questions on olded iterations Jul 26 07:06:04 ssn: please use [PATCH Vn] like [PATCH V2] then [PATCH V3] and so on when sending updated versions of a patch Jul 26 07:07:09 ssn: I asked you about your name spelling in the V1: https://patchwork.ozlabs.org/patch/1122661/ Jul 26 07:07:20 but you didn't reply to that and just sent V2? then v3 Jul 26 07:09:23 ssn: please also include list of changes below the tearline when sending V2, V3, etc. Jul 26 07:10:22 ah, so it was already reviewed, nice Jul 26 07:16:51 ssn: of course there is no point now in sending V4 if there aren't any changes needed Jul 26 07:17:09 ssn: still I would like you to check your name as I'm a bit confused regarding that Jul 26 07:17:39 (I think you used different name spelling in the past + you use different spelling when replying) Jul 26 07:18:00 maybe it's ok depending on your origin/country, please just check that Jul 26 07:24:16 it's not me sending them Jul 26 07:24:23 but I'll pass that on Jul 26 07:30:04 ssn: thanks Jul 26 07:31:13 rmilecki: do you think this is good to go now? Jul 26 07:34:49 The dev is Chinese, so name spelling is not consistent ;-) Jul 26 07:35:14 BTW should SW flow offloading work in QEMU as well? Jul 26 07:36:13 rmilecki: Please understand the language barrier is an issue Jul 26 07:36:52 ssn: ignoring questions is not a language barrier ;) Jul 26 07:37:02 ssn: that patch has been sent just today Jul 26 07:37:10 let people review it, wait few days Jul 26 07:37:13 I'll take a look at that too Jul 26 07:37:13 will do Jul 26 07:37:33 just wanting to help with communications Jul 26 07:37:56 Snowblind: ok Jul 26 07:37:59 ssn: ok Jul 26 07:38:11 Snowblind sorry, wrong autocomplete Jul 26 07:39:56 rmilecki: so should Luochongjun reply to your question with another patch / email? Jul 26 07:44:59 ssn: let me review V3 & ask if I need anything to be clarieid Jul 26 07:45:02 *clarified Jul 26 07:46:03 awesome, thanks Jul 26 07:51:36 if anyone brave, I have a k4.19.60 bump in my staging tree - compile & run on ath70 archer c7 v2 & x86 apu2 Jul 26 07:54:59 brcm2708 was the most problematic of the refresh so really could do with testing Jul 26 08:21:14 jow: (nitpick) would it be please possible to change domain in https://git.lede-project.org/251ded78f4a48683738de96ff9f7ed928868e75f URLs send to lede-commits@lists.infradead.org ? Jul 26 08:21:32 so one could copy&paste that directly, thanks! :) Jul 26 08:22:27 just saw your 'distro agnostic' changes Jul 26 08:57:13 ynezz: I do not understand Jul 26 08:58:56 currently in all emails with git changes sent to lede-commits@ mailing list, we still use lede-project.org domain name Jul 26 08:59:33 http://lists.infradead.org/pipermail/lede-commits/2019-July/011657.html 2nd line Jul 26 09:04:08 ah ok Jul 26 09:04:17 need to figure out where this comes from Jul 26 09:42:52 oh ffs 4.19.61 Jul 26 09:47:18 ldir: one thing I wonder... is there any value in bumping every little micro version in contrast to ... say every fifths? Jul 26 09:47:50 I could imagine that it makes rebasing and bisecting slightly easier but not sure if that outweights five times the effort to bump and rebase Jul 26 09:48:08 *fifth Jul 26 09:49:53 + the space on the download servers :) Jul 26 10:05:54 disk space is cheap Jul 26 10:06:20 I don't have a strong opinion on it other than 'it needs to be done and someone needs to do it' Jul 26 10:07:04 another consideration comes from Greg KH 'all user must upgrade' Jul 26 10:08:02 Hello guys. I am experiencing the fact that - if a flash region is not sectors-aligned, then the kernel won't read / write the last 256 bytes Jul 26 10:08:04 hm, valid points Jul 26 10:08:13 is this expected / documented? Because, if so, we should fix some devices I think Jul 26 10:09:02 In other words, if a region is 1280 bytes, then you will be able to read / write only the first 1024 of them. Jul 26 10:09:22 And this can stop users from doing proper flash backups / restore, from inside the kernel of course Jul 26 10:16:46 In other words - should we fix DTSes or the MTD layer or what? Jul 26 10:20:23 jow: usually you can find a few commits that are relevant to us in every changelog (e.g. 4.19.61 has fixes for mtk nand and spi nand, a btrfs data loss fix, qcom pcie fixes, stmmac fixes [found in e.g. iqp806x]) Jul 26 10:20:32 mrkiko: sounds like a mtd bug Jul 26 10:21:22 KanjiMonster: thank you very very much Jul 26 10:21:41 KanjiMonster: so maybe I should subscribe to their ML and report the issue? Jul 26 10:22:01 note that support for writing to non-aligned flash partitions is IIRC added through a patch from us; by default MTD would mark those partitions as read-only Jul 26 10:22:03 jow, blogic, nbd ... Jul 26 10:22:42 KanjiMonster: thank you very much for this hint... Jul 26 10:22:59 KanjiMonster: may this indicate that we are not supposed to write there at all? Jul 26 10:23:30 KanjiMonster: oh sorry - stupid question, I misread Jul 26 10:23:53 KanjiMonster: here, more than a partition alignment issue, I guess it'sa size alignment issue Jul 26 10:24:40 btw, are we talking about nor or nand flash? Jul 26 10:24:43 to put things in perspective - I am experiencing this with target/linux/ath79/dts/qca9561_tplink_archer-c60-v2.dts Jul 26 10:24:50 nor Jul 26 10:24:59 and in particular, it's "mac" partition Jul 26 10:25:19 I can confim you can read all of the region from the ar71xx target, not in the ath79 Jul 26 10:25:41 I sent some mails in the ML regarding this, one mail... but had no answer until now, so I wanted to have some more hints on this Jul 26 10:27:07 so you haven't actually tried to write; your issue is reading from it? Jul 26 10:27:36 (please don't try to write, just want to make sure the scope of the issue is clearly defined) Jul 26 10:29:40 KanjiMonster: Yes, the problem is reading. ahaha - I had to seek help for attaching a serial console to the device due to a mistake I did while trying to port the device to ath79 myself Jul 26 10:29:51 :D Jul 26 10:30:01 Yes, the problem is reading Jul 26 10:30:23 I did not try writing, if you want I might ... but no, I haven't tried Jul 26 10:30:45 I backed up the partitions when I firstly flahed openwrt @ ar71xx when device was new, so I have data to compare against Jul 26 11:53:43 I'm wondering: can you do an out of tree build with OpenWRT ? Jul 26 11:54:13 from a quick read of the source, it seems like all path refer to $(TOPDIR), which is always the top-level source directory, which probably means out-of-tree builds are not supported Jul 26 11:58:43 kos_tom: you could create build_dir and staging_dir symlinks pointing to somewhere else, if that's what you are after Jul 26 12:00:38 I was hoping for an O= variable, like the Linux kernel, U-Boot, etc. Jul 26 12:02:11 you can probably do that, just with more variables Jul 26 12:03:26 look at clean and dirclean targets for hint Jul 26 12:07:52 We have som fixes for ath9k, ath10k and ath179 in latest Kernel bump. Jul 26 12:08:00 some* Jul 26 13:28:23 KanjiMonster: is there a way for a tool built in tools/ to depend on a host library built by package/libs/ ? Jul 26 13:28:45 I have a new host tool in tools/, which needs libjson-c, and there is already a host package of libjson-c in package/libs/libjson-c Jul 26 13:29:06 I could certainly create tools/libjson-c/, but it seems like a duplication of package/libs/libjson-c Jul 26 13:29:27 overall, I'm a bit confused by the split between host tools built in tools/, and host tools built using the HostBuild macro in package/ Jul 26 13:31:07 kos_tom: no Jul 26 13:32:05 maybe you're just doing it wrong? Jul 26 13:32:19 ynezz: I'm all ears about what is the right way to do it :) Jul 26 13:32:25 and you should use HostBuild for your host stuff? Jul 26 13:32:33 package/libs/foo are not host packages Jul 26 13:32:42 kos_tom: mainly tools/ stuff is required by the buildroot itself (toolchain etc.) Jul 26 13:32:56 DonkeyHotei: wrong, several of them use the HostBuild macro, so that they can be built for the host Jul 26 13:33:09 HostBuilds of packages cannot be used before the toolchain is ready Jul 26 13:33:16 jow: I am packaging cryptsetup in tools/, as it is used during the filesystem image creation Jul 26 13:33:20 kos_tom: for example see https://github.com/openwrt/openwrt/pull/2267 Jul 26 13:33:37 so very much like squashfs tools, e2fsprogs, etc. and al. are packaged in tools/ Jul 26 13:33:52 kos_tom: he did exactly that, instead of using HostBuild macro, added the host tools in tools/ Jul 26 13:35:24 ynezz: hm, I must be missing something, I don't see any host tool added in tools/ in this pull request Jul 26 13:35:43 oh, github UI :) Jul 26 13:35:55 Well this is a new error https://paste.ubuntu.com/p/6QyDwGHqhz/ Jul 26 13:36:27 ldir: just fixed Jul 26 13:36:35 kos_tom: I can't find that first commit, weird Jul 26 13:36:41 I fell for mangix PR's once again :) Jul 26 13:36:44 if I were to use HostBuild to build my host tool, how do I make sure that it gets built before the filesystem image is generated ? Jul 26 13:37:09 kos_tom: you can't Jul 26 13:37:49 if you need something as part of the buildroot steps (tools, toolchain, image build steps etc.) it must be in tools/ Jul 26 13:37:55 so, my tool really needs to be packaged in tools/ Jul 26 13:38:08 jow: thank you Jul 26 13:38:11 so now, how do I make it depend on package/libs/libjson-c host build ? Jul 26 13:38:27 you can't. you'd need to build that as part of tools as well Jul 26 13:38:32 means duplicating it Jul 26 13:38:39 ok Jul 26 13:38:42 thanks for confirming Jul 26 13:38:52 I'll be posting the patches on the mailing list soon Jul 26 13:38:57 is there a json-c host build yet? Jul 26 13:39:00 I already posted a first version of dm-verity support back in March Jul 26 13:39:05 jow: yes, in package/libs/libjson-c Jul 26 13:39:17 ah right, for ucert etc. Jul 26 13:39:24 does not seems like cryptsetup needs libjson-c https://patchwork.ozlabs.org/patch/1054556/ Jul 26 13:43:05 ynezz: this patch was mine Jul 26 13:43:19 ynezz: and I missed the libjson-c dependency. I did a full clean rebuild now, and it fails to build like this: Jul 26 13:43:29 configure: error: Package requirements (json-c) were not met: Jul 26 13:43:33 ok, didn't know, that it was yours :) Jul 26 13:43:34 so it does require libjson-c Jul 26 13:44:02 so I guess it used to work because libjson-c for the host was built by package/libs/libjson-c due to some other dependency, and tools/cryptsetup used it Jul 26 13:44:23 but with a clean rebuild, there is no dependency between tools/crypsetup and package/libs/libjson-c, so the build fails Jul 26 13:44:54 makes sense Jul 26 13:45:52 maybe it would be easier to make hostbuilds usable for image building somehow Jul 26 13:45:58 by modifying the sdk Jul 26 13:46:13 porting more and more stuff to tools/ does not seem like a viable long term solution Jul 26 13:47:55 jow: I agree Jul 26 13:48:19 it's not really clear why there is this distinction between some host packages in tools/ and some host packages as "regular" packages in package/ Jul 26 13:49:27 15:32:36 < jow> kos_tom: mainly tools/ stuff is required by the buildroot itself (toolchain etc.) Jul 26 13:49:35 15:33:02 < jow> HostBuilds of packages cannot be used before the toolchain is ready Jul 26 13:50:59 back in the days, tools/ was for portability shims and uncommon host utils required to bootstrap buildroot Jul 26 13:51:29 as image generation and toolchains got more complex, more and more stuff was put there Jul 26 13:51:53 it was already too much for my taste when we put libressl and cmake there Jul 26 13:52:17 but those are absolutely required for the package toolchain Jul 26 13:53:06 for the record, I'm in fact primarily a contributor/co-maintainer to Buildroot, i.e the "original" one Jul 26 13:53:26 and in this original Buildroot, everything is a package, there is no distinction between stuff needed for the toolchain, or other packages Jul 26 13:53:41 but the architecture/constraints of the original Buildroot and OpenWRT are very different Jul 26 13:57:30 an easy hack I see would be making base-files conditionally depend on your crypt setup tool depending on some config symbol Jul 26 13:58:12 e.g. PKG_BUILD_DEPENDS:=CRYTPSETUP_IMAGES:cryptsetup/host Jul 26 13:58:25 in package/base-files/Makefile Jul 26 13:58:52 this would make base-files depend on the HostBuild of cryptsetup when CONFIG_CRYPTSETUP_IMAGES is set Jul 26 13:59:06 you should then be able to rely on it for image building Jul 26 13:59:17 as base-files is pretty much guaranteed to be included Jul 26 14:06:21 jow: sounds like a hack indeed :) Jul 26 14:08:31 less smelly than copying json-c into tools/ though Jul 26 14:09:07 the only thing preventing you from using HostBuilds for image build recipes is a missing explicit dependency Jul 26 14:09:23 PKG_BUILD_DEPENDS would solve that Jul 26 14:38:45 jow: seems like some of the buildslaves are not using the latest Docker buidslave image, thus not having python3 installed Jul 26 14:41:59 jow: http://buildbot.openwrt.org/master/images/builders/at91%2Fsam9x/builds/17 should we replace hexdump available with bsdmainutils or add it to the buildslave image? Jul 26 14:45:17 evening Jul 26 15:21:45 ynezz: or use `od` Jul 26 16:07:24 anybody knows why glib2 build depends on it's own host build? Jul 26 16:47:27 hmm, imagebuilder built with kernel 4.19 still depends on 4.14 if master is still on 4.14? Jul 26 17:01:29 i guess it make sense that I would have to set a local repository for kmod and other dependencies... Jul 26 17:30:04 romany: a few packages do that Jul 26 17:43:12 KanjiMonster: still there? Jul 26 18:04:35 mangix, few packages do what? Jul 26 18:39:34 mrkiko: sometimes Jul 26 19:08:56 KanjiMonster: :D Jul 26 19:09:04 well, alright :) Jul 26 19:09:25 KanjiMonster: I am going to "sleep" right now - just wondering if you had any idea on what we where talking about - flash regions and so on ... Jul 26 19:09:33 KanjiMonster: thank you for all the help Jul 26 19:09:35 good night guys Jul 26 19:36:56 wireless-regdb is not compiling for me: https://pastebin.com/LEcWQc8t Jul 26 19:37:14 ynezz: Jul 26 19:38:38 looks like a python 2->3 migration artifact Jul 26 20:51:58 gch981213: in commit a9360452, where you introduced target/linux/ath79/base-files/etc/init.d/bootcount, you used "boot()" instead of "start()" -- why? Jul 27 00:28:02 DonkeyHotei: It only needs to be called once when init is complete and users aren't supposed to call it. **** ENDING LOGGING AT Sat Jul 27 02:59:57 2019