Its not “build”, its source sode fork.
I see nothing that should stop luci from working if you include it into your build or install it later on from official upstream repos. Give it a try and ping me back, we can fix problems with it together if any.
As a general remark - I tried to keep changes in fork as minimal as possible compared to upstream. For the most part changes are things like configuring/teaching openwrt’s buildroot how to produce ready-to-use ext4-based SD card images for BPi R2, how to build u-boot that is compatible with R2 and so on. 99.9% codebase remain the same as it was/is in upstream.
Perfect, we can work on this together… I will see how I can build this from source and then test it, Then we can see how functional we can get and put luci in the img itself.
I always look at how a normal person can utilise my work. so it should be production ready for even a non technical person. I know this needs a lot of work and patience, but that’s how I like it
Thanks for your response and effort. I will try it tonight.
thanks @LeXa2, I couldn’t ask for a better explanation.
I have two more questions:
how many times per month do you sync your repo with OpenWRT trunk?
have you considered submitting patches to the OpenWRT project? maybe start with patches that allow proper ext4 image creation for instance, and then go from there?
thanks again for the time you put in writing such a complete answer.
I believe I had been mentioning it in other thread but it won’t hurt repeating here: I don’t follow OpenWRT trunk (a.k.a. master branch) as that will require too much attention from me. It’s a simple question of availability of “free” time to spend on maintenance which I unfortunately don’t have. I try to follow developments that are happening in “stable release” upstream branches but don’t have any hard schedule for this too - it’s happening from time to time when/if I see some real reason for updating R2 I’ve got working in prod. You know, things like security patches applied to LTS kernel in use and so on.
Typical cadence is like once per month, maybe once per two months. To be honest that’s more than enough to have your router sufficiently updated as most of packages in use get updates from opkg upstream binary repos so I only have to (re)build when there’s need to update kernel/modules and/or kernel-dependent packages like openwrt.
I’ve had a way more displeasing than acceptable experience trying to contribute to OpenWRT project like ~10 years ago. It was about adding support for yet another D-Link SOHO broadcom-based routed and fixing several bugs here and there. General attitude from the “receiving” side was ranging from ignoring to insulting so I abandoned my attempts and don’t want to visit that road again. It looks like this attitude is still popular in OpenWRT community (check this thread as an example: https://forum.openwrt.org/t/solved-strange-mksquashfs4-issue/38553 ).
Thus I prefer to benefit from the fact that it is open source software and tend to maintain my own forks for devices I use at home or supply as a “production grade” units to my clients and/or friends. When forks I maintain are non-specific enough to be of a possible interest for general public I tend to share changes at places like github - that’s the case for BPi R2.
Thanks for your reply.
The world has no shortage of stupid people. For my part, I believe that parting ways is a worst option than to expose them as you did on the thread example you posted.
The end result is that, your work ends up being available to much less persons and worst, these bad people are still around to scare away other contributors.
Anyway, it’s obviously your call. Thanks for sharing your point of view and course of action.
