Our objective is to import this version of dropbear to openwrt 19.07.02 to get ED25519 functionality.
We are able to 'replace' the package content in /package/network/service/dropbear, compile, and get positive results (I am able to SSH to my target using ed25519 key).
To be able to compile i was however required to manually insert my options in my 'diffconfig' file directly:
CONFIG_DROPBEAR_ED25519=y
#CONFIG_DROPBEAR_CHACHA20POLY1305 is not set
CONFIG_DROPBEAR_DBCLIENT=y
CONFIG_DROPBEAR_SCP=y
#CONFIG_DROPBEAR_DBCLIENT_AGENTFORWARD is not set
#CONFIG_DROPBEAR_AGENTFORWARD is not set
If i use the diffconfig.sh script, the resulting output will be whipped out:
#CONFIG_DROPBEAR_AGENTFORWARD is not set
#CONFIG_DROPBEAR_CHACHA20POLY1305 is not set
#CONFIG_DROPBEAR_DBCLIENT_AGENTFORWARD is not set
So basically, no more dropbear 
Does anybody knows a workaround to this ? It seems because my dropbear is a 'forward' version, diffconfig.sh script doesn't like that and whipe it out.
But make menuconfig seem to be able to 'understand' the contents of the 'new' dropbear's Config.in file since it displays all new options, and it does compile a successfull binary result.
How can i make it 'stick' with diffconfig.sh ?
Thanxs
It is not diffconfig which is not aware of it. It's the build environment.
Basically each package has its own makefile. For dropbear you will find it under:
package/network/services/dropbear
This is the configuration directory for the package itself and its options within menuconfig.
Relevant for changes within "Makefile" in your case are at least the following attributes:
PKG_VERSION:=
PKG_SOURCE_URL:=
PKG_HASH:=
PKG_CONFIG_DEPENDS:=
DB_OPT_CONFIG =
But my first approach instead of changing/patching the Makefile directly would be to just take the upstream Makefile and replace the original and see if the upstream package is working out of the box. But its a bit risky because /patches and /files directories content could conflict.
Otherwise you have to adjust the settings from above.
EDIT: To be more precise about the risky part. v19.x has his own patchset/configuration for its used version of dropbear as well as 20.x, 21.x and 22.x have its own. This is a risk in terms of: application is not running reliable/unexpected behavior and/or patches will not get applied properly. So inspect/compare especially the patchsets. Maybe you are able to sort out some. Because if I understand it right you didn't account this aspect so far.
1 Like
Yeah, this is mainly what i was doing and stating above and it did not work.
Ultimatly, it does not make sense because one wil do one day or another a dist-clean and whipe out those changes.
I did not mentionned this in my initial post but we also perform this on openwrt 18.xx. So solution is something else, i will post below.
So the solution is to create a new package under /package/companyname/dropbear-companyname
Then bring the tarball from dropbear 2022.82 to it,
Then modify the makefile and the confing.in and 'adapt' to be seen as a completely different package in menuconfig.
This solution works from A-z. It was a bit tricky at first because the build dir was not explicitly defined in the original makefile but by defining it everything copiles and work. Diffconfig keeps memory of selected items as well since they are part of what is now seen as another package.
1 Like
The clean way to approach this would be to use a separate branch that builds on top of 19.07 HEAD. You apply all your personal patches in that branch, and rebase as needed. If you make use of ./scripts/env on top of that, you can save build profiles and switch between those effortlessly.
2 Likes
As 18.xx - 22.03 are like frozen anyway you could just use "git diff > patchfile". If you want start from scratch you could use "git apply patchfile".
Anyway the approach working with git rebase from @Borromini is the better/more clean solution as you maintain a lot of different OpenWrt versions.
1 Like