It's all shiny and new, so it's really exciting to me right now.
Yeah, I have seen Kong's mentions of the kernel being a bit behind, though it doesn't need to be as they have already moved their broadcom units to Kernel 4.x some time ago. I think there is just not enough motivation from them to invest the time.
DD-WRT is really good on broadcom, no doubt about that. I did ask a few times in their forums about some of the discrepencies I saw in the builds (mvebu being lumped in with ath etc...) but never got a response. I moved on for now since then.
Now with LEDE/OpenWRT, I am only now realizing what I have been missing for years now. I really, really, really like the carte blanche offering this has.
Yeah, I saw the updates from Jan 2nd. But looking at the actual commits, they seem rather smaller in nature, and I don't think that including them in the builds will yield any world changing performance/stability gains to the community. One is just adding a missed value, and the other is just re categorizing EU as FR. So now FR has dup entries (30 and 32 IIRC).
Will add, not much movement on the 3200 driver/firmware side since last year (under Marvell control). So the stability issues everyone has been facing since then will all still be there. Fingers crossed for a larger update hopefully earlier this year. Especially since Belkin is about to release the new "black" version of the 3200, also promoting open source support.
So starting at the root of "base-files", you will see "/sbin/fan_ctrl.sh" has been removed, as well as "/etc/crontabs/root", since they are no longer needed.
Then, the "new" revision (04_mambafan) which should have been in the first place (@anomeome, things might seem familiar):
I think I tracked everything correctly this time (been googling a bit this afternoon, and correlating back to both of your instructions which make quite a bit more sense now).
Please share your thoughts if you would be so kind.
Ha, wee lil' bit distracted by the WJC gold medal round between CA-US, but... looks good, should solve the issue me thinks. Questions:
I thought deleted files showed as deleted, not a file with deleted lines, but maybe I am missing something when I look at your fork.
when no longer anything under a directory hierarchy, are you to delete the directory structure. maybe @hnyman knows?
-I thought I could create a patch and test it out for you against my build, don't see how, but back to my opening statement, not looking too hard at the moment.
WTF is the magic incantation to make bullet lists work in this SW?
Edit: now it pops up WTF, we're in OT. anyways in your working dir, does
git diff
generate a valid patch output?
Edit2: I just looked at the code again and it appears to have changed from when I first looked. I would question the correctness of the reorg, and would argue for the last incarnation that I pushed.
Edit3: Logic is flawed to my way of thinking. Don't need to check HI, sleep is in wrong spot. should check most likely condition first so as to spend least time possible.
I have built against it here locally and it seems to work fine. I am working on one small change right now, that is moving the sleep $INTERVAL from 88 to between 103 and 104, so the fan kicks in faster after boot (so figuring out that right now).
For the deleted files, I am not sure. I tried to do them with:
git rm root
git commit -s -m "blah blah"
git rm fan_ctrl.sh
git commit -s -m "blah blah"
EDIT: Okay, just cleaned it up. Will test locally once more.
Then I think I will make one more branch to do this change cleanly now that I seem to have a grip on it (so the timeline is clean, one shot). That is where I would publish the PR from....
Well, I am not even using mamba myself, but have just been giving feedback on the coding style. Feedback from real-life mamba users would be good for you.
Regarding the changes, I think that you should
combine the four commits into one. google for "git squash". Use "git rebase -i HEAD~4" to start the squashing/rebasing process.
chmod the permissions of /sbin/fan_monitor file to executable already in the commit, instead of setting that in uci-defaults. Git stores that info, but you need to set it it before adding & committing the file.
I did manually set the permissions within my dev env, however I was unsure if git also kept track of file permissions on local env, and then would save that when i committed back to the origin branch. That is why I had opted to also add the chmod command in the uci section. I can remove the unnecessary chmod in that case, one less step (redundant).
I will also work on squashing the commits into one.
Once I do that, is there a way I can publish this to my online repository so that mamba users can download the code as a patch to their devices (without me issuing the final PR)? I know @anomeome said he was not able to pull my (now removed) version from last night down to patch and test on his device. In the meantime, it is already available in my public builds.
It is easy to download a single commit from Github, once you get the hang of it. You simply add the the suffix ".patch" to the link to the commit's Github page.
But,
your commit modifies the files in the build system, so patch is good for people who incorporate the change to their own build. But the paths are wrong for applying to a live router. You should prepare a separate patch for that, and e.g. upload as a patch to gist.github.com
Example: support for cake qdisc (for SQM) was added to LEDE with my patch, and I made it available earlier for developers via gist. That patch is meant for the build system, but shows how a patch type of file can be easily provided: https://gist.github.com/hnyman/b35bf1e2501ad7dd08d4
Note that if somebody want to apply a patch in a live router, he needs to install the "patch" package first.
And unlike git, "patch" does not know about chmod permissions, so the chmod command is needed there.
Thanks for taking the time of walking me through this process. It is a good learning curve, but you all are helping me get there (and so patiently I might add)
Alright, with that said, your comment now gives me something more to go tackle now.
cybrnook - do you know if this latest build pulled in the latest miwifi driver updates, etc.?
Reason I'm asking is that per yuhhuarlin's comments here:
... as well as additional changes he referenced here:
... indicate there have been recent updates to support DFS (which I think may be relevant to the known issues for 5Ghz operation on these units - including the wr3200acm)
These appear to be incorporated into the latest mwlwifi driver (10.3.0.16-20160105)
If you can confirm - I'll update immediately and continue testing... otherwise - if you can let me know if you plan to include this in your next build???
Let me try and get the mamba fan thing I am working on out of my system, then will look at trying to bring the latest driver commits in. As of now, we are on the latest driver that has been committed to source, which is the Dec 22nd driver.
On the mwlwifi front,as regards the rango, a change with an updated 88W8964 blob is what will be of interest.
@cybrnook, just a guess from looking at your image, but... git add is about adding what you want in a commit, not about adding a file, also using "all" in it's various guises to add things to a commit will probably end uup causing more grief than relief.
So the basic gist:
create and change to branch
change/delete/add files
git add each file...
commit
push
Things should than be in your github, solicit feedback, and yes adding .diff or .patch to URL will generate a patch that someone else can apply to their build (my head was on that horrible defeat CA suffered at the hands of US last night)
Edit: Don't recall saying that but.. yes you make all change in branch, and add each file that you want in a single commit
But that's what I have been doing, however when I do it this way, my 4 x changes needed for this all get pushed up as individual commits.
I'm trying to figure out how to squash those 4 x commits (2 x deletions, 2 x additions) into 1 commit, and then push that...
EDIT: Oh wait a minute..... When you and I talked before, I was under the impression I was to issue a commit after each change (add or rm), so that's what I have been doing.
Are you saying I can just add/remove everything I need, then just issue 1 x commit at the end, signing and notating it?
You start the squash process with git rebase -i HEAD~4
Then you edit the automatically opened git rebase/squash control file to be like in the advice link you gave above (the "Hard mode: Squash commits" section). You "pick" the first commit and "squash" the other 3. You change the first word in each line. There is help on the screen.
pick fda59df commit 1
squash x536897 commit 2
squash c01a668 commit 3
Then you edit the combined commit message to be sensible.
Now you should have one commit in local repo. You push that to Github with "git push -f" in order to overwrite the original 4 commits.
It's all shiny and new, so it's really exciting to me right now.
(and so patiently I might add)