**** BEGIN LOGGING AT Wed Nov 04 02:59:57 2020
Nov 04 04:34:42 <FirstTime_NoTim> When I submit my patch for an additional ramips board - I will prepare the patch as described in https://openwrt.org/submitting-patches - and send an email to the maintainer mentioned in target/linux/ramips (as well as cc the mailing list?)
Nov 04 04:34:55 <FirstTime_NoTim> */Makefile
Nov 04 04:37:28 <FirstTime_NoTim> (I am also new to git - while I understand trees/hashes I have close to 0 practical experience with git)... to submit a new ramips device, which release / tag should I submit my patches against?
Nov 04 04:45:23 <Tusker> FirstTime_NoTim: master (trunk)
Nov 04 05:25:44 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 100.0% packages reproducible in our current test framework.)
Nov 04 05:35:07 <FirstTime_NoTim> @Tusker: thank you
Nov 04 05:36:20 <Tusker> you can have a look at https://github.com/openwrt/openwrt/pulls for examples of devices being added, and also have a read of the comments
Nov 04 05:36:29 <Tusker> so you can learn from others mistakes :)
Nov 04 05:37:06 <FirstTime_NoTim> I wanted to follow:
Nov 04 05:37:07 <FirstTime_NoTim> https://patchwork.ozlabs.org/project/openwrt/patch/20201020084435.11797-7-sander@svanheule.net/
Nov 04 05:37:45 <Tusker> sure, that looks clean, but the comments in the pulls are useful to understand what to watch out for
Nov 04 07:39:59 <aparcar[m]> jow: there are some issues with fakeroot, is it possible that's due to your patch? /home/build/openwrt/staging_dir/host/bin/fakeroot: line 185:  5565 Segmentation fault      (core dumped) FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" "$@"
Nov 04 07:40:14 <aparcar[m]> https://gitlab.com/openwrt/docker/-/jobs/828893239#L229
Nov 04 12:47:53 <adrianschmutzler> just had another look at the board.d bridge support patch now in master.
Nov 04 12:48:23 <adrianschmutzler> Do we actually support hyphens in uci config types but not in the config names?
Nov 04 12:48:56 <adrianschmutzler> Wasn't aware of that before ...
Nov 04 12:50:54 <adrianschmutzler> config names->option names
Nov 04 12:56:48 <karlp> well, I didn't see any of the demo config files that were used testing it either....
Nov 04 12:57:03 <karlp> I mean, it had typos that meant it hsouldnt' have worked, so, who knows what else was tested?
Nov 04 12:57:55 <adrianschmutzler> This is not really about the patch itself, I was just curious about this different in names and types for blocks and options
Nov 04 12:58:10 <adrianschmutzler> Never got aware of that before
Nov 04 12:58:38 <adrianschmutzler> we also have e.g. wifi-device with hyphen
Nov 04 12:59:03 <adrianschmutzler> but hyphen for option names yields parse error
Nov 04 13:25:55 <nitroshift> nbd, ping
Nov 04 13:27:08 <nitroshift> nbd, building 5.9 for mvebu:wrt1900ac v1 yields: "WARNING: Image file /home/nitroshift/nbd/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linksys_wrt1900ac-v1-kernel.bin is too big: 3207127 > 3145728"
Nov 04 13:27:24 <nitroshift> any way to decrease the size?
Nov 04 13:28:28 <adrianschmutzler> nitroshift: https://github.com/openwrt/openwrt/pull/3205
Nov 04 13:29:08 <nitroshift> adrianschmutzler, genius! Thanks
Nov 04 13:30:04 <adrianschmutzler> note that wrt1900ac-v1 is already disabled for buildbot with 5.4 due to the kernel restrictions
Nov 04 13:30:29 <nitroshift> adrianschmutzler, i know
Nov 04 13:30:53 <adrianschmutzler> an alternate option would be to drop certain kernel config options
Nov 04 13:31:38 <adrianschmutzler> this has been discussed heavily here: https://github.com/openwrt/openwrt/pull/3079
Nov 04 13:35:37 <rsalvaterra> adrianschmutzler: Uhh…? The mamba doesn't have a dynamic size kernel partition…?
Nov 04 13:36:07 <adrianschmutzler> rsalvaterra: Don't remember the details
Nov 04 13:36:35 <rsalvaterra> https://openwrt.org/toh/linksys/linksys_wrt1900ac#flash_layout
Nov 04 13:36:45 <rsalvaterra> It should be. That's weird…
Nov 04 13:41:16 <nitroshift> rsalvaterra, it's fixed to 3MB
Nov 04 13:43:26 <rsalvaterra> Hmm… I wonder if it's possible to teach that u-boot new tricks…
Nov 04 13:43:34 <rsalvaterra> … or replace it altogether.
Nov 04 13:44:04 <rsalvaterra> Dual-image is such a waste of space… :P
Nov 04 13:47:57 <slh64> dual-image isn't a waste of space, I really don't want to miss that feature anymore (nbg6817 here)
Nov 04 13:49:21 <slh64> I have never looked at mvebu, but the ipq4018 based ea6350v3 reserves 6 MB for the kernel, while the bootloader only reads the first 3 MB
Nov 04 13:50:09 <slh64> defined via uboot environment variable, so it should be possible to extend that limit
Nov 04 13:50:35 <slh64> just bad for upgraders or firstboot situations
Nov 04 13:51:56 <rsalvaterra> Yeah, I'm kidding, obviously dual-boot is useful. Nevertheless, it would be nice to be able to resize the partitions as needed.
Nov 04 13:54:00 <adrianschmutzler> nevertheless, there is no really satisfying solution for mvebu/cortexa9 at the moment
Nov 04 13:54:47 <rsalvaterra> adrianschmutzler: I know, right? Omnia owner here. :P
Nov 04 13:55:21 <rsalvaterra> Like I said before, the mamba is dumbing down the whole mvebu cortexa9 target.
Nov 04 13:56:41 <nitroshift> rsalvaterra, unfortunately you're correct
Nov 04 13:57:47 <rsalvaterra> Heh… In my tree, I just set the subtarget to neon (which also implies vfpv3-d32) and forget that mamba exists.
Nov 04 17:16:31 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Nov 05 02:12:54 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.)
**** ENDING LOGGING AT Thu Nov 05 02:59:57 2020