**** BEGIN LOGGING AT Sun Feb 21 02:59:58 2021
Feb 21 03:24:03 <mangix> lipnitsk: merged. let's see is anyone complains
Feb 21 03:24:23 <lipnitsk> haha, I like it. people are already complaining about refresh
Feb 21 03:25:06 <lipnitsk> The merge should make it easier at least for non-patch changes
Feb 21 03:26:05 <lipnitsk> Did you lock https://github.com/openwrt/packages/pull/14808 too?
Feb 21 03:32:15 <mangix> i did not lock it
Feb 21 03:32:28 <stintel> I did
Feb 21 03:33:08 <stintel> as I couldn't reopen it anymore because github is poop
Feb 21 03:37:18 <mangix> I wonder if anyone has an opinion on removing uClibc++
Feb 21 03:37:54 <stintel> nuke it already
Feb 21 03:38:11 <stintel> less is more
Feb 21 03:38:43 <mangix> It's much smaller (60.9 KB) than libstdcpp(278.1 KB) but buggier and dead development upstream
Feb 21 03:39:02 <stintel> 4MB devices are dead anyway
Feb 21 03:39:05 <hurricos> Anyone have any experience with OpenWrt misidentifying the quantyt of RAM on a board?
Feb 21 03:39:13 <hurricos> specifically Mediatek soc's doing so?
Feb 21 03:39:29 <mangix> Some have told me that it's possible to link statically and use LTO to reduce the size
Feb 21 03:39:30 <mangix> haven
Feb 21 03:39:31 <hurricos> MT7620 in a Newifi Y1 sees only 32MB
Feb 21 03:39:33 <mangix> 't tested
Feb 21 03:39:51 <stintel> hurricos: I believe there has been some talk about this recently. but I have no experience with it. I'd suggest to read ML/IRC archives
Feb 21 03:40:04 <hurricos> Thanks stintel, I'll dig
Feb 21 03:42:11 <rsalvaterra> Ok, building a new image for the Omnia… let's see if kab-el patch fixes my IRQ storm… :)
Feb 21 03:44:11 <stintel> rsalvaterra: up late, or early? :P
Feb 21 03:44:12 <mangix> rsalvaterra: link?
Feb 21 03:44:28 <rsalvaterra> stintel: still up… :P
Feb 21 03:44:51 <rsalvaterra> mangix: https://marc.info/?l=linux-arm-kernel&m=161386287915608&w=4
Feb 21 03:45:11 <rsalvaterra> Now tor failed to build, fml…!
Feb 21 03:45:49 <stintel> you're best to rm build_dir and staging_dir every time you build, otherwise something will creep in :P
Feb 21 03:46:02 <mangix> rsalvaterra: also enable ccache
Feb 21 03:46:14 <mangix> speeds up compilation after nuking build_dir
Feb 21 03:46:49 <mangix> ...why are there x32 patches?
Feb 21 03:46:58 <mangix> who uses x32?
Feb 21 03:47:16 <rsalvaterra> mangix: I would LOVE to use x32…
Feb 21 03:47:40 <mangix> why?
Feb 21 03:48:26 <rsalvaterra> Because 32-bit pointers with a 64-bit address space?
Feb 21 03:48:40 <rsalvaterra> Smaller i$ footprint?
Feb 21 03:48:45 <lipnitsk> how to get kernel_oldconfig/kernel_menuconfig to modify target/linux/generic/config-5.{4,10}?
Feb 21 03:49:27 <rsalvaterra> The x32 ABI was actually suggested by Knuth himself.
Feb 21 03:50:54 <lipnitsk> or is it only editable by hand?
Feb 21 03:51:00 <mangix> rsalvaterra: Sounds horrible. But then so is mips16
Feb 21 03:52:00 <rsalvaterra> mangix: You can't compare MIPS16 with x32… MIPS16 is a hardware feature, x32 is a pure software ABI.
Feb 21 03:52:58 <rsalvaterra> Aw, WTF…!
Feb 21 03:53:00 <rsalvaterra> src/lib/crypt_ops/crypto_openssl_mgt.c:256:15: warning: implicit declaration of function 'ENGINE_by_id' [-Wimplicit-function-declaration]
Feb 21 03:53:00 <rsalvaterra>   256 |   ENGINE *e = ENGINE_by_id("dynamic");
Feb 21 03:53:00 <rsalvaterra>       |               ^~~~~~~~~~~~
Feb 21 03:53:20 <mangix> which package?
Feb 21 03:53:33 <rsalvaterra> It's tor.
Feb 21 03:53:45 <mangix> you're building without engines
Feb 21 03:54:05 <rsalvaterra> Yes, as I always have.
Feb 21 03:56:56 <rsalvaterra> Hm… probably some dirty build, as stintel suggested.
Feb 21 03:57:23 <rsalvaterra> I'm going to bed, before the birds start to sing… :P
Feb 21 03:57:26 <stintel> I had to make package/foo/clean 4 or 5 different packages
Feb 21 03:57:39 <stintel> before my rpi build wanted to build
Feb 21 03:57:48 <stintel> it's incredibly annoying
Feb 21 03:58:38 <owrt-1907-builds> build #218 of ath79/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath79%2Fgeneric/builds/218
Feb 21 04:15:54 <hurricos> No dice in IRC logs. I did see https://forum.openwrt.org/t/ram-flash-variables/30912/7
Feb 21 04:16:10 <hurricos> Smells like U-boot doing something fucky
Feb 21 04:16:39 <hurricos> Sadly there are no serial pads onboard
Feb 21 04:19:13 <hurricos> Bootlod here suggests I can 'user define' the RAM: https://openwrt.org/toh/qihoo/c301
Feb 21 04:25:38 <hurricos> Oh, wait. It's U-boot. o_O
Feb 21 04:25:52 <hurricos> s/U-boot/Breed/.
Feb 21 04:26:39 <mangix> "While looking into it, I discovered that btrfs can't currently handle
Feb 21 04:26:40 <mangix> mounting a filesystem that was created on a system with a different
Feb 21 04:26:40 <mangix> page size." <--- wtf is this
Feb 21 04:26:53 <hurricos> btrfs is very broken :\
Feb 21 04:27:17 <hurricos> * can't grow it without mounting it
Feb 21 04:27:30 <hurricos> it breaks a lot of filesystem expectations
Feb 21 04:27:36 <mangix> it's perfectly fine in my experience
Feb 21 04:28:08 <hurricos> It's kind of like OpenWrt. Lot more hands-on than other filesystems
Feb 21 04:28:43 <stintel> eek
Feb 21 04:28:55 <stintel> thats reallt insultinf
Feb 21 04:29:09 <hurricos> I love OpenWrt to death but I'm glad I understand it
Feb 21 04:29:26 <hurricos> It's a lot less situational than filesystems too. You can't just copy openwrt from one router to another.
Feb 21 04:30:50 <stintel> because no router is the same
Feb 21 04:31:08 <mangix> lolwut?
Feb 21 04:31:16 <stintel> you can however restore a backup from apu2 to erl for example
Feb 21 04:31:21 <mangix> you can move a btrfs volume from one computer to another
Feb 21 04:31:34 <stintel> because they happen to have the same interface layout
Feb 21 04:32:49 <hurricos> mangix: Not if it was created on a system with a different page size
Feb 21 04:32:50 <hurricos> :^)
Feb 21 04:33:10 <mangix> hahaha good point
Feb 21 04:33:19 <hurricos> and don't get me wrong. Like 99 times out of 100 if you swap your entire main router out
Feb 21 04:33:22 <mangix> to be fair, most platforms have a 4K pagesize
Feb 21 04:33:25 <hurricos> you can restore a sysupgrade -b dump
Feb 21 04:33:38 <hurricos> and the config will "just work"
Feb 21 04:33:44 <mangix> still weird
Feb 21 04:33:48 <hurricos> which is really the equivalent.
Feb 21 04:37:53 <owrt-snap-builds> build #796 of layerscape/armv8_64b is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/796
Feb 21 04:57:38 <owrt-1907-builds> build #215 of samsung/s5pv210 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/samsung%2Fs5pv210/builds/215
Feb 21 05:41:41 <owrt-snap-builds> build #780 of armvirt/32 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F32/builds/780
Feb 21 06:01:36 <owrt-1907-builds> build #210 of mpc85xx/p2020 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mpc85xx%2Fp2020/builds/210
Feb 21 06:21:04 <hurricos> I am very confused. The RAM issue solved itself somehow after multiple reboots.
Feb 21 06:22:01 <hurricos> I should have thrown this guy away long ago, probably, to avoid just this situation :thinking:
Feb 21 06:33:18 <Grommish> It's a Cavium.  I see hard-locks on a classy reboot where the watchdog just goes nuts.  I had to power cycle to reset
Feb 21 07:11:03 <owrt-1907-builds> build #217 of brcm63xx/smp is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm63xx%2Fsmp/builds/217
Feb 21 07:15:33 <damex> Grommish: cavium3 should not have that happening unless something goes completely wrong.  what exactly is going wrong with watchdog?
Feb 21 07:16:36 <Grommish> dunno, but every once in a while I get that register dump from the watchdog when it attempts to reboot, never consistently though
Feb 21 07:17:03 <Grommish> which requires a full power pull to clear
Feb 21 07:31:23 <Pepe> lipnitsk: That's not about complaining. My opinion about refreshing patches is that it should not be mandatory. We are adding more bricks into the wall against contributors. Which is bad. If we are fixing typo, the build should proceed and should not says: "Ehm... patches are wrong.". Even we do tree wide commit where we fixes patches, I think that refreshing patches should be opt-in.
Feb 21 07:34:00 <Pepe> Even these days there is lack of contributors in PRs. They can not do Signed-off-by, then dont do compile either run test and so on. Sometimes it is stalled or they are getting angry if they should write commit message. :(
Feb 21 07:35:18 <lipnitsk> alternatively, we could add infrastructure to refresh them more easily (without having to clone openwrt). But yeah, if there is evidence that it impedes contributions you have a point. Nothing wrong with teaching proper commit etiquette though. Being friendly is one thing, accepting unmaintainable or messy changes is another.
Feb 21 07:37:20 <olmari> Exactly... keeping up maintainability and thus general quality of coding etc should be kept up to high standards... ways to achieve that more easily is then again very welcomed... in mine opinion :)
Feb 21 07:39:06 <Pepe> But doing refresh can lead to some issues, so its better to get it run tested again even small changes can go badly. Someone does not want to do that don't know why in case of php packages, but anyway. In CI there is no possible to skip patches step and thus force you to do that, which was my point. Others projects have possibility to skip some of those tests, we don't have it. But I agree with you on
Feb 21 07:39:07 <Pepe> this guys, but as I said there are not many contributors these days and we are making it harder and harder for someone
Feb 21 07:40:14 <lipnitsk> refresh is just commiting what quilt already does every time it prepares a package for build, we are just commiting the truth into the repo. If it's broken the patch needs to be fixed
Feb 21 07:40:47 <Grommish> What if you don't use quilt?
Feb 21 07:41:09 <lipnitsk> there is argument about the superfluous changes, but it's more about getting into the habit of refreshing, or making that a more easy process somehow?
Feb 21 07:42:08 <lipnitsk> how do you test your changes then? You need to at least compile it with openwrt, right? Or just rely on CI? :)
Feb 21 07:42:34 <Grommish> I meant for patch creation, sorry.  Don't mind me
Feb 21 07:42:51 <Grommish> I realized after the fact I'm wandering into an argument ;p
Feb 21 07:43:17 <Pepe> The truth is that a lot package maintainers are rely on CI these days. :(
Feb 21 07:43:42 <lipnitsk> ya you can create the patch however you want, just run make package/feeds/packages/<your_pkg>/refresh. But if that last step is difficult for a lot of contributors then we do have a problem
Feb 21 07:44:35 <lipnitsk> Maybe we should at least put the command into the PR template
Feb 21 07:44:40 <Grommish> Sadly, I'm on of the ones Pepe referenced earlier regarding Commit messages.  But, I freely admit I got pissy about the situation, but he was right in the situation
Feb 21 07:45:12 <lipnitsk> maybe a cool web app to refresh your patches? LOL
Feb 21 07:45:30 <Grommish> I'd rather have standards than not, because I rely on people with more knowledge making the decisions on what get's committed
Feb 21 07:45:34 <lipnitsk> I think the main point is achieving a balance that makes maintainers as well as contributors happy
Feb 21 07:46:09 <Pepe> This. +1
Feb 21 07:46:34 <lipnitsk> so discussion should continue and the change can be easily turned off if needed.
Feb 21 07:47:16 <Grommish> Discussion should always continue..  If nothing else, it'll show why it won't work - at least for now, or why it should be done.  Info is good, more is better
Feb 21 07:47:56 <lipnitsk> Grommish: it's very humbling working with a large FOSS community - I know it's a learning for me because I haven't really been brewing in these circles much
Feb 21 07:48:22 <lipnitsk> good learnings, but time needs to be invested. And time is what a lot of people don't have..
Feb 21 07:49:03 <Grommish> I know I started very upset with adrianschmutzler because I thought he was being overly anal-retentive about commits ;p
Feb 21 07:49:15 <Grommish> Unti I saw what happens when you aren't ;/
Feb 21 07:50:36 <Grommish> (I also took it as a personal attack, wrongfully because I was of the mindset I tested this already.. ahem.. Not a bright spot for me)
Feb 21 07:52:29 <Grommish> In any case, I don't understand the CI stuff anyway, except my package breaks it due to space limitations, but I'm all for standards
Feb 21 07:52:38 <lipnitsk> ultimately, whatever gets more users onto the platform is probably the right way to proceed
Feb 21 07:52:56 <lipnitsk> btw github is a blessing, at least for the package repo
Feb 21 07:53:36 <Grommish> Not if the quality drops *shrug* I could run Tomato on my R8000 if I wanted to settle for the 3.x kernel to use the cts.ko mob, but I want something that isn't going to cause me to wonder
Feb 21 07:53:53 <Grommish> Costs me half my paid for throughput to do go
Feb 21 07:54:58 <lipnitsk> trying out matrix, let's see.
Feb 21 07:57:38 <Grommish> Besides, nothing stops anyone who doing their own thing.  The target I commited for my device only covers 1/3rd of the device space, I locally maintain the other 2 slot functionality
Feb 21 07:57:45 <Grommish> doesn't mean it should be part of the repo
Feb 21 07:59:10 <Grommish> but I can host it as a fork, I can and have run forks of the packages defined for the custom cpu arch setting
Feb 21 07:59:21 <Grommish> CONFIG_ALL takes forever ;p
Feb 21 08:19:52 <mangix> what i miss?
Feb 21 08:25:35 <owrt-1907-builds> build #220 of ramips/mt7620 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Fmt7620/builds/220
Feb 21 08:27:33 <ynezz> what about just refreshing the patches in the CI, providing the diff output as downloadable artifact with copy&paste instructions in curl|git am format? Some projects are doing similar for failed code style checks for example
Feb 21 08:28:52 <ynezz> so even if the CI check fails, author has relatively easily actionable fix in hand
Feb 21 08:29:56 <mangix> sounds pointless
Feb 21 08:30:03 <mangix> you can just run make package/x/refresh
Feb 21 08:30:08 <mangix> much easier than git am
Feb 21 08:30:20 <Grommish> If the CI check fails, they've got the logs, no?
Feb 21 08:36:28 >KGB-2< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 98.4% packages reproducible in our current test framework.)
Feb 21 09:35:48 <owrt-1907-builds> build #213 of ramips/mt7621 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Fmt7621/builds/213
Feb 21 09:37:17 <mangix> aparcar[m]: hahaha well played. The reason the treewide patch missed it is because there's a different directory for patches based on BUILD_PATENTED.
Feb 21 09:37:50 <aparcar[m]> mangix: uhm?
Feb 21 09:37:58 <aparcar[m]> tell me more
Feb 21 09:38:25 <aparcar[m]> is make refresh always "safe"?
Feb 21 09:38:41 <Borromini> hey guys. i set the DTS to extract the MAC from the device's ART partition, a dump shows it's there, but ag71xx tells me 'invalid mac' and uses a random one. what am i doing wrong? https://paste.debian.net/plain/1186293/
Feb 21 09:39:13 <Borromini> 00 22 3f 0d 06 12 is what the MAC is
Feb 21 09:42:13 <mangix> It is safe yes.
Feb 21 09:43:28 <mangix> aparcar[m]: those patches are used when BUILD_PATENTED is disabled. I'm guessing lipnitsk has it enabled locally.
Feb 21 09:44:00 <mangix> fdk-aac is one of those problematic packages
Feb 21 09:47:25 <aparcar[m]> okay anything I should do?
Feb 21 09:47:52 <mangix> No.
Feb 21 09:48:09 <mangix> The PR is fine
Feb 21 09:48:37 <aparcar[m]> great fftm
Feb 21 09:54:21 <aparcar[m]> mangix: refresh on openssl doesn't look right:  package/libs/openssl/patches/430-e_devcrypto-make-the-dev-crypto-engine-dynamic.patch     | 2646 +++++++++++++++++++++++++++++++++++++++---
Feb 21 10:00:34 <plntyk> Borromini, <&art 0x0>; <- art at 0x0 offset instead of 1000 ?
Feb 21 10:02:35 <plntyk> Borromini, examples: grep -R "mtd-mac-address" target < -in source tree
Feb 21 10:04:47 <aparcar[m]> mangix: https://github.com/openwrt/openwrt/pull/3899
Feb 21 10:07:44 <Borromini> plntyk: so it should try 0x1000? ar71xx mach file has this: https://paste.debian.net/plain/1186295
Feb 21 10:08:27 <Borromini> i assume ksegaddr 0x1fff1000 translates to 0x1000?
Feb 21 10:24:20 <mangix> aparcar[m]: the problem is that quilt cannot handle file renames. It interprets it as a file deletion and rename
Feb 21 10:25:56 <aparcar[m]> yea I guess the patch is just garbage
Feb 21 10:26:00 <mangix> https://github.com/openwrt/packages/blob/master/utils/open-vm-tools/Makefile#L86 is a solution.
Feb 21 10:29:11 <svanheule> Borromini: I assume you have the art partition at a base address of 0xff0000 (and size 0x10000) in your flash layout?
Feb 21 10:29:53 <svanheule> Borromini: the number in mtd-mac-address = <&art ...> is the offset inside that partition, so 0x1000 as your hexdump shows
Feb 21 10:30:53 <plntyk> what svanheule said
Feb 21 10:32:04 <plntyk> just did some sunbathing ... really sunny in Berlin
Feb 21 10:35:34 <Borromini> ok thanks guys
Feb 21 10:35:59 * Borromini is for sure gonna read a bit on his east/south balcony today
Feb 21 10:37:38 <Borromini> svanheule: art is 0x0000003f0000-0x000000400000
Feb 21 10:38:01 <Borromini> so base addr 0x3f0000
Feb 21 10:38:16 <svanheule> ok, but the mac address is still at offset 0x1000, right?
Feb 21 10:38:32 <Borromini> yes that's a dump of that art partition
Feb 21 10:38:48 <Borromini> i don't know why i thought it was 0x0 when it clearly shows 1000
Feb 21 10:38:54 <svanheule> :P
Feb 21 10:39:06 <Borromini> :P
Feb 21 10:41:18 <owrt-1907-builds> build #234 of layerscape/armv7 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/layerscape%2Farmv7/builds/234
Feb 21 10:43:00 <rsalvaterra> 'morning!
Feb 21 10:43:37 <Borromini> aloha.
Feb 21 10:43:48 <Borromini> i gotta say i am appreciating the blessings of git commit --amend
Feb 21 10:44:48 <rsalvaterra> Borromini: How have you lived until now without it? :)
Feb 21 10:45:06 <Borromini> rsalvaterra: lots of git resets and wondering why :P
Feb 21 10:45:20 <rsalvaterra> My greatest epiphany was when I discovered git rebase -i. :)
Feb 21 10:45:29 <Borromini> what does that do
Feb 21 10:45:34 <Borromini> interactive rebase?
Feb 21 10:45:36 <rsalvaterra> Oh, my…!
Feb 21 10:45:42 <rsalvaterra> Yes, interactive rebase.
Feb 21 10:45:53 <Borromini> ok. i'll try that one time :P
Feb 21 10:46:37 <rsalvaterra> Borromini: No. You will understand what it does, then you will do it all the time, especially when iterating patch series. ;)
Feb 21 10:47:10 <rsalvaterra> It's so incredibly powerful it almost feels like magic.
Feb 21 10:48:21 <Borromini> ok
Feb 21 10:50:25 <rsalvaterra> And now to try and build my Omnia image again… hopefully make clean solved my tor/openssl errors…
Feb 21 10:51:24 <Borromini> ;)
Feb 21 10:54:48 <Borromini> seems eth0 is coming up but no mac, eth1 isn't, but wiphy is detected
Feb 21 10:55:01 <Borromini> not too bad for my first own dts i'd say :P
Feb 21 11:05:45 <ldir> interactive rebase with the 'fixup' command - perfect commits first time
Feb 21 11:06:15 <Borromini> neat
Feb 21 11:06:59 <PaulFertser> Borromini: the trick used by old ar71xx code is to use a big offset, so no matter what the flash size is, the extra top bits will be ignored, and you'll end up referencing 0x10000 before the end of the flash. And 0x1000 into it.
Feb 21 11:07:13 <Borromini> PaulFertser: ok, thanks
Feb 21 11:07:29 <Borromini> i'll need some help getting eth1 up but one step at a time :)
Feb 21 11:32:33 <rsalvaterra> mangix: Hm… even after make clean, tor-basic fails to build. :/
Feb 21 11:41:19 <owrt-1907-builds> build #210 of ath79/tiny is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath79%2Ftiny/builds/210
Feb 21 11:46:15 <rsalvaterra> mangix: Something's really wrong. I can't build tor without openssl engine support.
Feb 21 11:46:28 <rsalvaterra> I wasn't a problem in the previous stable version.
Feb 21 11:46:32 <rsalvaterra> *It
Feb 21 12:12:35 <Pepe> rsalvaterra: Can you create an issue in packages feed? My colleague is updating it regularly and having some log output would be nice. I will ask him to take a look at it anyway.
Feb 21 12:13:20 <rsalvaterra> Pepe: Will do. I was registering to create an issue in the Tor project itself. :P
Feb 21 12:14:15 <Pepe> That's will do as well!
Feb 21 12:15:36 <rsalvaterra> Done for the packages feed.
Feb 21 12:16:10 <rsalvaterra> Yeah, but registration is moderated, so it could take a while before it's even approved… :/
Feb 21 14:55:51 <eliasmagn> Does someone know if it is possible to download file from http/s with cgi-io.
Feb 21 15:03:53 <plntyk> there is small wget -> uclient-fetch for that
Feb 21 15:09:45 <eliasmagn> thank you
Feb 21 16:31:20 <Hauke> zorun: do we need https://git.openwrt.org/891022918d55b565b49b7ecafc4ebf8a66461a13 also for 12.02?
Feb 21 16:33:21 <zorun> Hauke: yes, good catch
Feb 21 16:33:48 <zorun> I don't remember the details but I hadn't found a clean solution that would work on any branch
Feb 21 16:34:03 <zorun> so for now a similar change is needed for each branch
Feb 21 17:05:15 <Borromini> had to do something similar yes for 21.02
Feb 21 17:43:42 <zorun> Hauke, Borromini: I have just pushed it to openwrt-21.02
Feb 21 17:50:14 <Borromini> ty
Feb 21 17:52:34 <Hauke> zorun: thanks
Feb 21 18:59:31 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (99.1% images and 98.4% packages reproducible in our current test framework.)
Feb 21 19:00:30 <owrt-2102-builds> build #9 of layerscape/armv8_64b is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/layerscape%2Farmv8_64b/builds/9
Feb 21 19:23:41 <rsalvaterra> Hauke: ping
Feb 21 20:00:30 <Borromini> hey guys. trying to port a wnr2000 v1 from ar71xx to ath79. it's an ar9132 device according to what i could find, with an ar8126 switch. ar71xx had a ath79_eth0_data.has_ar8216 setting that i'm not finding an ath79/dts equivalent for?
Feb 21 20:01:11 <Borromini> network setup code from mach-wnr2000.c is https://paste.debian.net/1186352/ and my dts so far is https://paste.debian.net/1186351/
Feb 21 20:04:37 <plntyk> the eth0_data.has_ar... might only mean that the "eth0" port on the SOC is attached to an ar8216 (or compatible) switch
Feb 21 20:05:41 <plntyk> https://forum.openwrt.org/t/solved-swconfig-router-and-switch-gl-inet-ar150/21718/5 like diagram here
Feb 21 20:05:48 <plntyk> post 5
Feb 21 20:07:54 <plntyk> Borromini, some tplink archer devices that are afaik already ported have ar8337 which is similar to 8216
Feb 21 20:08:48 <Borromini> plntyk: ok, take a look. grepping master for 8216 isn't returning anything though
Feb 21 20:10:20 <plntyk> archer C7 v1 has ath79/dts/qca9558_tplink_archer-c.dtsi included
Feb 21 20:11:34 <Borromini> ok seeing some mdio stuff there
Feb 21 20:11:59 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Feb 21 20:12:51 <Borromini> it doesn't look like there's lots of ar9132 stuff ported.
Feb 21 20:42:28 <Hauke> rsalvaterra: pong
Feb 21 20:44:16 <rsalvaterra> Hauke: Finishing a v3 for mvebu 5.10. Correct me if I'm wrong, but device tree patches should have a prefix index of 3xx, right?
Feb 21 20:44:31 <rsalvaterra> After all, they're arch-specific.
Feb 21 20:45:22 <Hauke> rsalvaterra: for the targets we do not really use these rules
Feb 21 20:45:36 <Hauke> if they are backports from a more recent kernel I would prefer low numbers
Feb 21 20:45:46 <Hauke> so 0xx
Feb 21 20:45:53 <rsalvaterra> Well… are the rules written anywhere? :)
Feb 21 20:46:12 <Hauke> I think nobody folows these for the targets ;-)
Feb 21 20:46:29 <Hauke> I think there is a rule  about backports
Feb 21 20:46:42 <rsalvaterra> Newcomers can only read rules which are written somewhere… :)
Feb 21 20:46:58 <Hauke> are these device tree changes backports from more recnt kernel versions or new patches?
Feb 21 20:47:37 <rsalvaterra> It's a mix of backports and a new patch, (finally!) fixing the IRQ storm on the Omnia.
Feb 21 20:48:56 <rsalvaterra> Anyway, it's probably two or three patches. I'll reindex them from 0xx, as you suggested.
Feb 21 20:49:20 <Hauke> The file in target/linux/generic/PATCHES says that upstream backports should get a 0x prefix
Feb 21 20:49:42 <Hauke> and code which is already send upstream and is probably getting merged soon should get 1xx
Feb 21 20:50:15 <rsalvaterra> Ok, in that case, the IRQ fix will be 1xx, since it was sent upstream for review yesterday evening.
Feb 21 21:17:17 <rsalvaterra> Hauke: Build-testing the A{53,72} targets…
Feb 21 21:33:21 <lipnitsk> mangix: yeah, I didn't disable BUILD_PATENTED. Probably should fix the CI script to look for 'patches*' dirs, not just 'patches'
Feb 21 21:33:59 <rsalvaterra> Heh… Looks like I'm still not done. The ESPRESSObin build is screaming bloody murder. :P
Feb 21 21:36:42 <zx2c4> Hauke: got a chance to review lipnitsk's patchset and merge it?
Feb 21 21:37:15 <zx2c4> https://github.com/openwrt/openwrt/pull/3885
Feb 21 21:37:34 <zx2c4> Pretty significant amount of work there
Feb 21 22:16:48 <bkallus> I have a BCM63xx router to which i'm trying to port openwrt. the stock firmware doesn't have any tools to dump the nand, and i'd like to make a backup. I have it booting from initramfs images over tftp, but openwrt can't see the mtd partitions. How do I tell the boot process where the mtd partitions are?
Feb 21 22:17:20 <bkallus> i have a root shell on the stock fw, so i am able to read /proc/mtd.
Feb 21 22:20:07 <lipnitsk> bkallus: off the top of the head - check your devicetree config, nand driver.
Feb 21 22:23:10 <PaulFertser> bkallus: but is it able to see the NAND at all? Because if you just need to dump all of it probably you do not need partitions. Sometimes the layout is hardcoded, sometimes there's some kind of partition table, depends on the vendor.
Feb 21 22:31:28 <zx2c4> lipnitsk: im trying to repro that guy's issue...
Feb 21 22:32:43 <lipnitsk> yeah I'm having no luck. iperf fail is probably a red herring, but maybe not - 5.10 support is still in early stages. There are a lot of things enabled in his config and a lot of variables - which SHA is he building from, at what SHA are his packages, etc..
Feb 21 22:34:56 <lipnitsk> That said, the WireGuard makefile changes are completely independent of linux 5.10 and a minimal build with luci-app-wireguard for his target works just fine
Feb 21 22:35:26 <zx2c4> So seems like just noise
Feb 21 22:35:59 <lipnitsk> and he confirms that the minimal build with wireguard works in his comment https://github.com/openwrt/openwrt/pull/3885#issuecomment-782920797 (first paragraph)
Feb 21 22:36:19 <zx2c4> but then he says
Feb 21 22:36:21 <zx2c4> "If that is directed at me, my presumption is that what I am seeing directly related to this PR. if I did not think that I would not be posting here. But if you think that a real config failing just by enabling what this PR targets..."
Feb 21 22:36:25 <zx2c4> so :shrug:
Feb 21 22:37:50 <lipnitsk> I'll spend a bit of time on it just to cover our bases and maybe to report some new unrelated issue.
Feb 21 22:51:25 <zx2c4> lipnitsk: so far so good
Feb 21 22:51:30 <zx2c4> mine built iperf successfully too
Feb 21 22:51:47 <lipnitsk> good. you took his config and disabled ccache?
Feb 21 22:51:57 <zx2c4> i checked out your branch
Feb 21 22:52:04 <zx2c4> `git-am`'d those patchwork patches onto it
Feb 21 22:52:10 <zx2c4> copied his config to .config
Feb 21 22:52:21 <zx2c4> enabled wireguard
Feb 21 22:52:21 <zx2c4> hit make
Feb 21 22:57:24 <lipnitsk> okay, I'm gonna try the same but without wireguard first to see if I can get to where he got in the second paragraph, then enable luci-app-wireguard and try again.
Feb 21 22:58:10 <rsalvaterra> tmn505: ping
Feb 21 23:07:02 <rsalvaterra> I'm completely baffled by the fact that one file in the 5.10.16 kernel we download differs from the one in gregkh's 5.10.16 tagged commit. This is pre-quilt patching, obviously. Can someone enlighten me, please?
Feb 21 23:07:51 <lipnitsk> we download it from kernel.org and validate the hash, so you should ask there :)
Feb 21 23:09:04 <rsalvaterra> I do make target/linux/{clean,prepare} V=s QUILT=1. The armada-3720-espressobin-v7.dts is different. What gives…? o_O
Feb 21 23:18:35 <zx2c4> lipnitsk: i managed to repro!
Feb 21 23:18:42 <bkallus> PaulFertser, lipnitsk: Thanks. It's not able to see the nand at all yet. I'll get that working first.
Feb 21 23:18:58 <lipnitsk> zx2c4: good job! how?
Feb 21 23:21:01 <zx2c4> lipnitsk: https://א.cc/pUfQNQ0J
Feb 21 23:22:44 <lipnitsk> some weirdness with kpp then? I'm still building the no-wg version, will add luci-app-wireguard and try to get it here too
Feb 21 23:23:39 <lipnitsk> it sort of makes sense then, since the minimal build probably needs no KPP, but when it is needed things break
Feb 21 23:24:22 <zx2c4>   DEPENDS+=+CRYPTO_KPP:kmod-crypto-kpp
Feb 21 23:24:26 <zx2c4> i wonder if that's working
Feb 21 23:25:07 <lipnitsk> well you could try removing 'CRYPTO_KPP:' to force it
Feb 21 23:27:48 <Hauke> rsalvaterra: it would be very strange if they are different
Feb 21 23:28:29 <rsalvaterra> Hauke: It's surreal to me. Check this out: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts?h=v5.10
Feb 21 23:28:46 <rsalvaterra> This is even at 5.10
Feb 21 23:30:01 <Hauke> rsalvaterra: how does it look like in the tar.xz?
Feb 21 23:30:05 <rsalvaterra> And this is my file: https://paste.debian.net/1186371/
Feb 21 23:31:19 <rsalvaterra> I'm refreshing all the patches again, because it seems I can't trust the kernel tree… :/
Feb 21 23:31:31 <tmn505> rsalvaterra: check the files
Feb 21 23:31:41 <tmn505> directory
Feb 21 23:32:11 <tmn505> You have to delete some of the dts which are upstream
Feb 21 23:32:28 <rsalvaterra> *facepalm*
Feb 21 23:32:45 <rsalvaterra> sigh…
Feb 21 23:33:03 <Hauke> it overwrites the file with target/linux/mvebu/files/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
Feb 21 23:33:07 <Hauke> rsalvaterra:
Feb 21 23:33:16 <tmn505> that's why I said they have to be split for 5.4 and 5.10
Feb 21 23:33:52 <rsalvaterra> Yeah, I obviously understand the problem now.
Feb 21 23:34:03 <rsalvaterra> Sorry for the noise… :/
Feb 21 23:34:38 <tmn505> np
Feb 21 23:35:44 <lipnitsk> zx2c4: still having package build failures... though not iperf anymore. did you run ./scripts/feeds update -a && ./scripts/feeds install -a ? It's either some package discrepancy or my host system is just too bleeding edge and some issue there (I'm running Arch)
Feb 21 23:41:27 <zx2c4> lipnitsk: yea, i did
Feb 21 23:43:09 <lipnitsk> getting "/usr/lib/libpython3.9.so: file not recognized: file format not recognized" while building uwsgi now... maybe because it's a symlink on my system?
Feb 21 23:43:09 <lipnitsk> $ file /usr/lib/libpython3.9.so
Feb 21 23:43:09 <lipnitsk> /usr/lib/libpython3.9.so: symbolic link to libpython3.9.so.1.0
Feb 21 23:44:44 <lipnitsk> why is it even trying my system python? It should be using ./staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/lib/libpython3.9.so
Feb 21 23:45:01 <lipnitsk> ugh, I'll try and get past this..
Feb 22 00:09:33 <zx2c4> lipnitsk: just do it on towner
Feb 22 00:09:44 <lipnitsk> good idea.
Feb 22 00:09:58 <lipnitsk> I'll debug my system later.
Feb 22 00:45:03 <lipnitsk> zx2c4: okay, finally reproduced it. will work on it now
Feb 22 00:55:37 <blocktrron> lipnitsk: I've merged your 5.10 packaging changes, Will start some tests on 5.4 and 5.10 on some targets prior to merge
Feb 22 00:55:58 <lipnitsk> thanks, do you have changes on top of mine or just those?
Feb 22 00:56:04 <blocktrron> ping me here or via E-Mail in case you don't hear back on that
Feb 22 00:56:06 <blocktrron> Just those for now
Feb 22 00:56:13 <lipnitsk> great, thanks.
Feb 22 00:56:35 <blocktrron> Just don't @ me on GitHub, i don't have notifications for that
Feb 22 00:56:53 <lipnitsk> understood
Feb 22 00:56:54 <blocktrron> I mean, you can do that but it won't help with anything :P
Feb 22 00:57:08 <lipnitsk> I know how to best bug you now
Feb 22 00:58:11 <blocktrron> I'll have to catch up on the state of wireguard.
Feb 22 00:58:53 <blocktrron> I don't have a strong opinion on which way to go, as long as the ugly party disappear once 5.4 is nuked
Feb 22 00:59:11 <lipnitsk> yes, working out a kink or two, but it is looking good. Don't be scared by all the patches there - zx2c4 signed up for maintaining that. The main question is what to do about 21.02 I think
Feb 22 00:59:30 <mangix> lipnitsk: keep using the module?
Feb 22 00:59:41 <zx2c4> blocktrron: ugly party?
Feb 22 00:59:59 <zx2c4> mangix: im not going to maintain wireguard-linux-compat on openwrt anymore
Feb 22 01:00:08 <zx2c4> that's old crusty code that doesnt have a reasonto exist in openwrt land
Feb 22 01:00:15 <lipnitsk> mangix: you mean, keep using wireguard-linux-compat on 21.02?
Feb 22 01:00:49 <blocktrron> zx2c4: ugly not in that sense, i refer to that bug pile of patches as being rather ugly while performing eventual kernel updates
Feb 22 01:00:58 <blocktrron> not sure how much they interfer though
Feb 22 01:01:12 <zx2c4> blocktrron: oh. theyre usually pretty standalone
Feb 22 01:01:19 <mangix> lipnitsk: the question is why not.
Feb 22 01:01:21 <zx2c4> i maintain that tree over gregkh's
Feb 22 01:01:21 <rsalvaterra> It would be nice to kill wireguard-linux-compat from 21.02 too, if still possible… :/
Feb 22 01:01:58 <lipnitsk> mangix: maintenance? fresh release with crusty old stuff doesn't sound like a good idea. 21.02 branch is still young and these patches are stable
Feb 22 01:03:09 <mangix> note that exfat in the kernel is also implemented as a module
Feb 22 01:03:23 <mangix> since it was introduced with kernel 5.8
Feb 22 01:03:54 <blocktrron> zx2c4: that sounds good. And I've meant "big pile", not "bug pile". That's easy misunderstood :P
Feb 22 01:04:01 <blocktrron> blame my fat fingers
Feb 22 01:07:02 <lipnitsk> zx2c4: CRYPTO_KPP probably doesn't jive with what's written towards the end of https://openwrt.org/docs/guide-developer/dependencies#dependency_types section - trying to make sense of it now.
**** ENDING LOGGING AT Mon Feb 22 02:59:57 2021