Build for WRT3200ACM (Discontinued)

[cybrnook]

@anomeome @hnyman , where can I send you guys some beer money too?

So thanks @hnyman, for whever reason I decided to use your google advice instead of just taking what you gave me.

Thanks worked: https://github.com/cybrnook/source/commits/mambafan

But of course, I am sure the singing off is now, wrong correct?

And seriously, how can I pay you guys back. You both are basically teaching me git over a forum thread....

[hnyman]

@cybrnook

the singing off is now, wrong correct?

Yes. You forgot the step

Then you edit the combined commit message to be sensible

And I think that you have not used chmod before committing /sbin/fan_monitor , so Github does not show it executable.

You should likely chmod that executable, commit that change. then do one more git rebase -i, but this time with HEAD~2 to combine the new commit to the previous one. And you can edit the commit message at the same time.

EDIT: My bad. It is shows executable in the file view, but not in the patch view,
not here: https://github.com/cybrnook/source/commit/dc89fc236159bc02a57570667bb9a759e85ba5d9
but here: https://github.com/cybrnook/source/blob/dc89fc236159bc02a57570667bb9a759e85ba5d9/target/linux/mvebu/base-files/sbin/fan_monitor

[hnyman]

@cybrnook

You both are basically teaching me git over a forum thread....

Learning git takes some effort, and you need a concrete real task to practice with. So your small change gives you a really good practice target.

I guess that after today you are much more ready to contribute to the development

[cybrnook]

@anomeome

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

Makes more sense, I got it! Thanks buddy.

[cybrnook]

@hnyman

@cybrnook

You both are basically teaching me git over a forum thread....

Learning git takes some effort, and you need a concrete real task to practice with. So your small change gives you a really good practice target.

I guess that after today you are much more ready to contribute to the development

Getting there, let's give this one more shot! I am determined to work this through, no matter how small

[anomeome]

Now for the part where you swear under your breadth in my general direction. I still argue that the logic could not only be better, but is flawed. See my Edit3 some posts back.

[hnyman]

@cybrnook

I am determined to work this through,

One more command for you:

git commit --amend

can be used to edit the message of the last commit.

[cybrnook]

@anomeome

Now for the part where you swear under your breadth in my general direction. I still argue that the logic could not only be better, but is flawed. See my Edit3 some posts back.

No swearing you're way at all, I borrowed quite a bit of code from you in my builds. Will take a look now and see what you are talking about.

EDIT: ah yes, I corrected that yesterday already. And even told you I was doing so but I think you were watching TV

[quote="cybrnook, post:126, topic:545, full:true"]

@anomeome

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?

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).[/quote]

The HI I will take a look at now.

@hnyman

@cybrnook

I am determined to work this through,

One more command for you:

git commit --amend

can be used to edit the message of the last commit.

Thanks, I have seen this quite a bit, but now that you put it in context, I see the very useful purpose of this.

[cybrnook]

FINALLY!!!! https://github.com/cybrnook/source/commit/4398a011a59a0cbe1d3b768171831a5fb8d3e68b

@anomeome , like you just mentioned (reviewing the logic). I actually sat down for the past couple hours and went like by line through the logic and a bit of changes compared to what we whipped up before. My goal was to remove as much of the fluff as needed to try and keep it as simple as possible.

In the meantime, I am going to compile it and see if it works as expected.

and @hnyman, finally managed to confidently roll all my changes into one commit and publish to my feature branch. (Doing good as long as I don't have to make any changes now )

EDIT: annnnnd just messed it all up because I wanted to correct a small typo I saw....... starting over again.....

[hnyman]

@cybrnook

Doing good as long as I don't have to make any changes now

Well, if you need any change, you just add one more commit to the branch and then squash those two commits together so that things are nice and tidy again. Pretty much the same things that you have done already.

I think that you have now gone through most tasks needed for editing & publishing work via git (and Github). There is nothing really special, but there is definitely a learning curve as you have noticed.

[cybrnook]

Massive learning curve , but I want to see it through!

Will test the HEAD~2 now...

EDIT: success, I cleanly fixed, squashed, and force-ably pushed to my feature branch. It's back to being clean ( I think)

[hnyman]

Note that hash changed, so your link above is wrong.

[cybrnook]

Better: https://github.com/cybrnook/source/commit/338f1e6145db64549b112bca6274c474ffd0410e ?

Just to test, I am going to add one more # comment and upload to make sure I have a grip on making changes.

[cybrnook]

Okay, I think I got it (thanks to both of you guys): https://github.com/cybrnook/source/commit/0c47225f587a16bd89e9a1a360686d57c6e1037b

[hnyman]

Easiest for others may be if you give the link to the commit log of that branch, because your commits should be there first and the address stays the same despite your changes / additional commits: https://github.com/cybrnook/source/commits/mambafan

[cybrnook]

Makes sense, and keeps it "universal" (no changing hash).

So now that I got it rolled up into my feature branch. Is there a way I can now pull it down to incorporate it into my LEDE builds, before issuing a PR against LEDE? (and without just manually hacking it in there)

two different paths I am using, feature branch/personal repo is:
/cybrnook/source

and my snapshots are
/lede/source

I already assume it will be a combination of something like "git pull" or "git clone" or even "git remote add..." against my feature branch. While being located in my /lede/source folder.

But issue the "right" commands and in the proper order are what I would need a helping hand on.

[hnyman]

@cybrnook

Is there a way I can now pull it down to incorporate it into my LEDE builds,

Well, several ways, depending a bit if you build from the same repo or not.

• If you normally build from the same repo using master branch, you could build this time from "mambafan" branch.

• In the same repo you could also "git cherry-pick" the commit to another branch. Very useful command.

• If you use a separate repo (like you edited while wrote this message), you can either copy the few files separately or use git commands to generate patch(es) that you can easily use for transfer to your main repo:

  git checkout mambafan
  git format-patch 88ca6390ea (= hash of the last official commit before your new commits)

  Patch file 0001-mvebu-replace fan_ctrl-sh-with-daemon-for-mamba.patch will be generated to the directory where you are. One patch file will be generated for each commit after 88ca6390ea.
  copy that patch file to your build repo's root dir
  cd to that dir. ( apparently /lede/source )

  Apply the patch with

  patch -p 1 -i 0001-mvebu-replace fan_ctrl-sh-with-daemon-for-mamba.patch

  or

  git am 0001-mvebu-replace fan_ctrl-sh-with-daemon-for-mamba.patch

  (the git am command creates a commit out of it. Patch does not)

(you can also check success first with: patch --dry-run -p 1 -i 0001-... )

I have been building a community build for WNDR3700 for some 5 years now. Some feedback on my own workflow:

• I use a clean separate repo for "send Github PRs" and another one from which I build the firmwares and where I do the actual changes first and test them.
• I transfer files between then manually (by "cp" etc.) or using patches like I explained above. I haven't bothered to connect the two repos, as I don't always first transfer things to Github.
• I do not usually generate commits before I really want to transfer things to Github and show them for others. Editing files normally in the local repo and compiling is quite possible without creating a commit.
  • If you do NOT generate a commit, "git diff HEAD" works and shows differences.
• In connection of a firmware build I create full diffs of all my changes in main repo and all feed repos, for each build. Comparing them visually (with Winmerge in Windows, meld in Linux) to the diffs from the previous build makes it easy to spot unexpected changes in upstream sources, config etc.
• I also publish the full diffs with each build, enabling others to copy by changes for their own build. See https://www.dropbox.com/sh/t52c02rm20y8x9p/AABNHwoEsyaRgC_KViBGhY5Da/lede-r2709-b7677f05d6-20161231?dl=0 for an example
• I actually also provide a script that creates a copy of my whole build environment in about 5 minutes with all my patches applied I use it myself to transfer my own environment to a clean Ubuntu every few months.
  You can see that process in Build for WNDR3700v1/v2 / WNDR3800 (discontinued) - #2 by hnyman

[cybrnook]

Solid gold! I have to take off for a few. But I am going to have to sit a read this a few times.

It seems easy enough (too easy, so doomed for trouble) to just pull the path and copy it over. Who woulda thunk it!

Thanks so much for taking the time to spell it out. As well, you can always point others trying to learn to this thread, it has a wealth of knowledge in here people would pay good money for!

[cybrnook]

@hnyman

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.

Another piece that has now saved me from my headache..... I have been wonder why in the hell the patch was ignoring the permission that the "patch" itself is clearly labeling they need (as I have been using the patch -p 1 -i ...). git am worked much better........(I see the difference now when git and patch are used. git for building, patch for live)

Building now against latest lede and my patch applied.

[slh]

GNU patch, in contrast to git am, ignores access permissions and just uses the default umask settings.