are scripts/files within board.d and uci-defaults both combed during first boot and ran? (I know uci-defaults, as I use that currently)
I need to know where to drop the script at, AND have it run (assuming during first boot) so it can determine which model router it is. I don't think this would qualify as a uci-defaults z* script, would it? But then again it might since this is a one off case......
Can you help me understand what is happening with the scripts already in here with names like 01_, 02_ , 03_
Like in etc/board.d or in /etc/uci-defaults
Could I just place this in board.d or uci-defaults named "04_mambafan" ? And it would be the 4th "setup" script that would run on first boot for mvebu devices? And since I have an exit 0 , it will end clean either way, thus being deleted after first boot?
I would question doing this after the fact though. To my way of thinking, better to just not put it into the build unless mamba, instead of removing something you don't want.
I am going to do a test commit here in a little bit to try and show you what I mean.
@anomeome , quick question. After I have made my changes (a few file/folder deletions, and creation of a file). What is my process for the "git add" command.
Can I just:
git add target/linux/mvebu/base-files
and catch all the files behind that (recursive), thus catching all my modifications?
I am at @jow 's example of:
$ nano package/kernel/mwlwifi/Makefile
$ git add package/kernel/mwlwifi/Makefile
Best to add each file that you want part of the change, rather than" -a or ."
git add file
git commit -s -m "mvebu: blah" -m "description"
git push origin branch
That is now in your fork and I could peek
Edit: since you are starting you will have to:
git config --global user.name "REAL NAME"
git config --global user.email real.email@provider.com
git config --global core.editor "nano"
Edit2: git should track all changes, if in the branch,
git checkout master
git branch -d | -D branch
Should get things back to before changes. you may have to clean up github, whether from your environs or on the website.
Edit3: I assume you would just
rm file
and git would see the change. got'ya, ya I guess that would be the way.
Edit4: Just a note on your PR. I assume someone will ask you to amend the PR and add a signed off by email. You will have to add the above git config for name and email; that is the -s option on the git commit, I assume the same name on your github account. Take a look at pending PRs for an example of correct form, and this
what if I want to delete a file or an entire folder (that is no longer necessary). How do I track that change?
And, as advised, I follow the instructions and made a branch (and have since deleted files/folders/made updates). Let's say I want to scrap what I did and start over to more cleanly track my changes. Can I do that (even though I have deleted things), or do I need to re clone again? Or scrap (and everything magically shows up again?)
Alright, so I have made the "test" changes and committed them to my fork.
Oh geez...... I seem to have publish this against LEDE source as a PR Well, I guess the worst that can happen is it get's denied. Best case it get's approved, and then we take the next step afterwards. Which would be then converting it to the daemon.
@cybrnook
Github hint for you. You don't need to close the PR for modifications. It is enough that you add new commits to the same branch and update the PR with "git push". You can even overwrite older commits with "git push -f" (e.g. after squashing/rebasing several commits into one that replaces the original commit). Useful advice can be found in https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md#advice-on-pull-requests
Additional Github hint: Your fork does not update automatically. (It is currently 266 commits behind lede-project:master)... There are now new commits in LEDE master, but your Github fork needs to be updated manually to see them. In practice you need to first pull new commits into your local repo directly from LEDE upstream master and then push those changes into your fork master at Github. You need to declare Github LEDE master as a "remote" repo for that.
And finally rebase the "feature branch" to start from the current HEAD (instead of the month old code) to ensure that it merges without problems. And push it to the Github branch overwriting the previous commits forcibly:
git checkout modernize-fan_ctrl.sh
git rebase master
git push -f
Thanks for the response on the PR, as well as your very detailed response above. I understand that I could work on amending/fixing up the initial PR, however I felt it was better to start fresh anyways. Truth be told, I never intended the PR from last night to be submitted against the LEDE trunk. It happened more on accident as I was just creating my first test PR, and going through the motions as I get more comfortable with the basics of using git ( to which I am attempting to learn ). I thought I could just publish a PR against my own fork, before submitting it to LEDE for approval, seems it all happened in one swoop. As well, seems my fork is out of date, but that is something else I will need to look into as I find that strange as I just forked LEDE source last night prior to testing the PR. So I find it odd that it's 200+ commits out of date. Perhaps this is because I forked LEDE some time ago, just playing around, and have since deleted it from my git? Now that I forked again, it just brought back what I originally had? Will look into it......
With that said, I would much rather submit another, clean, fresh PR that represents what I would actually like to see happen, rather than a tattered one with multiple edit's and revisions. This would be the removal of the cron job all together, and instead creating the fan "daemon". This would allow us to remove the defined "root" crontab, the crontabs folder, the fan_ctrl.sh scripts, as well as the sbin folder from the base folder structure.
However, I need a clean way to "deploy" the daemon files, and enable them. Thus I would attempt to use the same logic I attempted to demonstrate in my initial (unintended) PR, as that is the best approach I can see as far as deploying something during first boot (making the 04_mambafan uci script). A quick "if" then.... else it get's deleted, using the mvebu_board_name function.
Likely you just reactivated the original fork in Github and made a new local copy of it. I guess that you have not fully deleted your fork at Github. (Deleting it done via the "Delete this repository" in the repo options in Github GUI.) Your local repo is a completely different thing, just a local incarnation of your fork in Github. You may even have several different copies locally. And you may safely delete the local copy without any effect on the fork origin at Github.
You need to keep your Github fork's remote copy at Github , the "origin", updated like I showed above.
Working with git, Github and PRs is rather nice one you get forward on the learning curve. But you need to always keep clearly in mind the difference between
fork's local copy (where you edit things, and which is just a throw-away dirty copy)
fork origin in Github (into which you push commits and use to publish PRs, and which you manually keep in sync with LEDE upstream)
LEDE upstream in Github (from where you mainly pull changes and where the PRs are visible for others).
Principally you edit everything locally, and when it is ready you push it to the fork origin in Github, after which others can see the commits in your Github repo. After that you can propose the commits to be accepted into LEDE upstream master via PRs.
And as nature would have it, even though when I originally deleted my forked copy (using the "Delete this repository" , enter repository name to confirm) the first time, I guess it just brought it back last night when I forked again. I say this because I did the same motions just now, deleting the forked copy, and then re-forking LEDE and it now says "This branch is even with lede-project:master." - Yeah Yeah, I know you will think I did something silly, but either way I seem to be current now so that's a good starting point. I will work on manually keeping this fork up to date as I go.
The difference between my local copy (on my dev env), my forked git repo, and of course LEDE's repo. As well, it makes sense that all the work I do on my dev env is local to my box, up until the point where I commit it to my forked repo ("origin"). What I got confused on last night, was after I committed my local changes to origin, I did not see any published PR's in my remote copy. So I thought that other users would not be able to see my changes (without having to manually search my entire fork, down to the folder level). So I thought that by clicking the create PR from changes button would publish the PR only against my local fork, not yet going against LEDE. That's how this PR ended up in your lap to begin with, me just trying to learn the mechanics. I thought there would have been yet 1 more step before I would be able to take my PR, and then publish that against LEDE.
The commands, and understanding that I need to work on is on my local (dev env) copy (the "throw away" as it's being called). I hear a lot of terms on this with , throw away, stash, base, rebase, branch, rebranch, force etc..... This is where I need to become proficient. As well as general rules of thumb, like @anomeome pointed out to me. Things like correctly registering my name, email, editor. As well as the switches needed to correctly tag and mark the changes -s and -m, and the need to have to do this after each and every change. I originally thought I could just walk into my local dev copy and modify all to my hearts contents, and then wrap it all up in one command and publish that as a change to my "origin", noting what it all was at that time.......
Anyways, I will start over this evening with the newly gained info, and the actual intended changes. The picture is a little clearer now.
[quote="cybrnook, post:116, topic:545"]
So I thought that other users would not be able to see my changes (without having to manually search my entire fork, down to the folder level). So I thought that by clicking the create PR from changes button would publish the PR only against my local fork, not yet going against LEDE.
[/quote]Yeah, others can see your branch and commits that you have pushed to your Github fork origin, (but naturally not any stuff that is in just your local repo). And others can even clone your fork or download individual commits from it.
To get others to notice things during development, you might need to say in the forum that please check my new stuff on topic XXX in my branch ZZZZ. One good example is the thread about ipq806x thermal sensor driver development/backport that contains a lot of work-in-progress links commits in dissent's Github repo. Supporting thermal sensors on ipq806x
PR is needed only in the final step when you want to ask the code to be imported into LEDE upstream master.
The example you provided is good. I see there can be many steps, changes along the way prior to a PR being released.
I will create a new branch this evening and will reach our prior to publishing a PR.
If/When I create a branch off my master copy. When I issue future pull requests to resync my master against the current lede trunk, will this also update my branches? Or once a branch is created, this is now it's own independent copy, needing a pull request itself? (or is this now getting into the difference between tree's vs branches?)
Well, you clearly need git basics. I suggest that you google a bit about github, forks and PRs.
[quote="cybrnook, post:118, topic:545"]
If/When I create a branch off my master copy. When I issue future pull requests to resync my master against the current lede trunk, will this also update my branches? Or once a branch is created, this is now it's own independent copy, needing a pull request itself?
[/quote]No, no no... Do not mix "git pull" (= update local copy from a remote repo) and "pull request" (= Github term for proposing your commits to be included upstream in the upstream master in Github). The word "pull" is used in both contexts, but there is a huge difference.
You do not issue "pull requests" to sync your master against the current lede trunk. You issue a "pull request" in Github GUI when you propose to upstream developers that some new code from you (that you have already pushed to your Github fork) should get included in the upstream lede trunk.
You do local updating with "git pull" command, specifically "git pull upstream master" to update your local copy with new commits from lede trunk. (And then you do "git push" to update also your Github fork with those changes. Otherwise it remains stale.)
If you talk about updating your local code with "git pull", you need to update each branch separately. Each branch has its own log of commits included. Thatswhy I gave the "git rebase master" example above, where you first updated the local master branch with "git pull upstream master" and then you checkout out and refreshed (=rebased) a feature branch with the changes in that master. That avoids creating merge commits.
Learning to work with git branches fluently takes some time.
This is what I meant. Sorry for misusing git pull and pull request. What I meant (in my head) was when I "pull" the git changes from source to me repo. not issuing a PR.
I think we are just talking too much in the details from a few different topics this morning.... reminds me of a saying "can't see the forest through the tree's"
Boy you are busy with builds right now.
Just installed r2763 on my wrt1900acs v1. Running fine so far. I do not use OpenVPN so cannot report on that. I see there is a new wireless driver released, but no one seems to have incorporated it yet.
I see you are getting mentioned on DD-WRT site as having a good build. Talking about better throughput. Kong has stated that the kernel being 3.x rather then 4.x is part of their throughput issues.
cybrnook - I've been running your latest build (r2763) on my wrt3200acm.
Compared to a few builds ago this one is fairly solid - though still seeing the router crap out after awhile necessitating a reset (this gets logged quite a bit when it happens):
Thu Jan 5 08:04:45 2017 kern.err kernel: [25122.279018] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Thu Jan 5 08:04:45 2017 kern.err kernel: [25122.284880] ieee80211 phy1: return code: 0x001d
Thu Jan 5 08:04:45 2017 kern.err kernel: [25122.289427] ieee80211 phy1: timeout: 0x001d
Thu Jan 5 08:04:45 2017 kern.err kernel: [25122.293632] ieee80211 phy1: failed execution
Thu Jan 5 08:04:49 2017 kern.err kernel: [25126.298972] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Thu Jan 5 08:04:49 2017 kern.err kernel: [25126.304839] ieee80211 phy1: return code: 0x001d
Thu Jan 5 08:04:49 2017 kern.err kernel: [25126.309387] ieee80211 phy1: timeout: 0x001d
keep up the good work! - also been trying davidc502's builds as well....
I'm interested if the latest updates to the driver will help with the wifi issues (intermittent drops)...
Well, I guess the worst that can happen is it get's denied. Best case it get's approved, and then we take the next step afterwards. Which would be then converting it to the daemon.
.
Talking about better throughput. Kong has stated that the kernel being 3.x rather then 4.x is part of their throughput issues.