Build for WRT3200ACM (Discontinued)

@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:

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....

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:
but here:

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 :slight_smile:

Makes more sense, I got it! Thanks buddy.

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

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.

One more command for you:

git commit --amend

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

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 :slight_smile: but I think you were watching TV :stuck_out_tongue_closed_eyes:

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

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.

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


@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 :wink: )

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

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. :wink:

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.

:slight_smile: 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)

1 Like

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

Better: ?

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

Okay, I think I got it (thanks to both of you guys):

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:

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:

and my snapshots are

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.

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


    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 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 :wink: 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

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!

Another piece that has now saved me from my headache..... :slight_smile: 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.

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

1 Like