OpenWRT from LUCI to Gargoyle

[patpat]

it didn't work...
I've updated with SVN UP and failed...
I've checked out the packages again (revision 15627.) and failed...
I've updated again and also failed....

[Eric]

Try checking out branches/packages_8.09 instead of packages. Those are the packages that are associated with the 8.09 release, and don't have any of the more recent updates that may be breaking things.

[patpat]

I think the point is that the packages are copied from

Code: Select all

trunk/package

to

Code: Select all

trunk/custom-src/package

by the command

Code: Select all

sh full-build-809.sh custom

I was just updating

Code: Select all

trunk/package

and performing a

Code: Select all

/trunk/custom-src make

and was always failing.

Now I'm performing the long

Code: Select all

sh full-build-809.sh custom

let see what happens

Comment: your job is good and please take my comment as a constructive personal opinion... I think gargoyle build chain should follow OpenWRT build chain... Openwrt allows to check out from 8.09 branch, 8.09 tag, or trunk, the same with its packages. Why gargoyle is not somehow added to the standard OpenWRT building schema as an extra set of packages and scripts ??
It takes 20 minutes understanding how to build plain/LuCI OpenWRT, dont you think building Openwrt with Gargoyle support takes "unnecessarily" much longer than that?

[patpat]

it failed again...

I'd love to build OpenWRT with Gargoyle support having full control when it comes to check out components.
Now I can check packages out from branches/packages_8.09 but I don't know where is Gargyle checking OpenWRT out from, nor if the combination won't be broken either......

[Eric]

I just updated (in the svn) the build script so that when you build a custom image, all of the optional packages in packages_8.09 automatically get checked out and made optional. This should solve your problem. Check out the latest Gargoyle source and see if it works.

There are a couple reasons the build process for Gargoyle is a little bit more complicated to modify than LuCI:

1) In order to build the default firmware images and packages, you need to enter exactly one command (run the build script with no parameters). In order to build LuCI, not only do you need more than one command, but you need to configure it using make menuconfig. Most of the time I don't want to mess with this -- I just want to build the default image, with whatever changes I've added to the default packages. While using the build script to do this makes it a little less straightforward to add things, it makes it easier to build the default.

2) I can build for multiple platforms with only one command. With LuCI, I need to reconfigure for every platform. With Gargoyle, I can run one command, and everything builds. No further configuration necessary.

3) Unlike LuCI, Gargoyle patches the OpenWrt build scripts and modifies the target linux kernel patches. When you install via a feed you can't do this. Some major features, like bridging on Atheros devices, and custom iptables modules require these modifications.

If you have a better idea how I can retain these advantages, but make it easier to customize, please let me know. I'm always looking for ways to improve. However, my belief is that ease of building the default is more important than ease of customization.

[patpat]

I'll try it later and I'll post results

About the building process I understand your points but I think (just my personal opinion)

1) Customization is OpenWRT's soul; if a user does not need customization mikrotik or dd-wrt are probably better options...
OpenWRT users love customizations...

2) I think keeping all those OpenWRT+Gargoyle images is somehow overlapping OpenWRT well done job.

3) I think gargoyle is an OpenWRT GUI and your job should clearly separate the GUI from any other underlying process. if you added the Client Bridge functionality to OpenWRT that should be a "package" (I know is not one) separated from gargoyle GUI. There are people that do not use GUIs that probably want to add this feature, why to force them to install gargoyle in this case?

4) about building Gargoyle I think it should be based on OpenWRT building schema, something like this:

checking out Openwrt
checking out Openwrt Packages
checking out Xxxx (Gargoyle underlying components)
checking out Gargoyle (GUI)

running Xxxx script patching things
running gargoyle script patching things
running make menuconfig (OpenWRT)
running make

[Eric]

1) It's not that customization of Gargoyle is impossible, it's just requires an extra step or two. With the new automatic download of openwrt packages I added yesterday it should still be fairly straightforward. This is a trade-off for allowing even easier building of defaults options.

2) I really don't know what you mean by this

3) I already DO separate the backend and front end parts to the best of my ability. All of the GUI code is in the gargoyle package -- all of the others are back-end packages. The client bridge is a very special case because it has 2 parts, one of which is a patch to the kernel, while the other is a hotplug script. Yes, the client bridge hotplug script is part of gargoyle package, even though it's not GUI, but I don't know where else to put it. I don't really want to make a separate package called "client bridge" with just the hotplug script, because that script alone (and therefore the package) won't work. The bulk of the implementation is in the kernel patch, which can't be part of a package. If you have a better suggestion how to separate this, I'm all ears.

4) The problem is that you need a script to run things as you describe. That script would be part of Gargoyle, and in your description you have Gargoyle being checked out after OpenWrt. There's a chicken-and-egg problem there. You have to check out Gargoyle first because then you get the build script, and while you're checking that out, you might as well check out the rest too. That's exactly what I do now: you check out Gargoyle (both back-end and front-end packages), and that checks out openwrt & openwrt packages, applies patches, and builds.

[patpat]

1) I know, I know, I was just remarking the fact that the customization factor is very important for the OpenWRT comunity

2) for you is very important being able to produce all the possible OpenWRT with gargoyle support binary images, and from my point of view its more important having an easier integration for those who build their own images... I might be wrong on this..

3) if I were you and the Client Bridge functionality really works w/o affecting the bridging performance I'd put all my effort on making the Client Bridge a Gargoyle independent "package".
About how to separate things I think gargoyle is storing the Client Bridge parameters somewhere and the hot plug script is doing its job on start up or something like that and you can turn on and off that script from gargoyle, ok how can you do that w/o the GUI? just put some parameter on a conf file and trigger the script file when needed.. if gargoyle can do it, the plain command line can do it too. Probably this topic deserve some discussion time on OpenWRT forums...

4) you check out Openwrt and its packages,
later you check out Gargoyle (mostly some packages + some scripts) you put the packages in the openwrt package directory and the scripts wherever u want...
later you run the gargoyle scripts that patch openwrt kernel etc.
later you build OpenWRT as usual,
is anything wrong with this?
Checking out under my command let me chose what I'm getting your system doesn't allow that

[Eric]

1) We can definitely agree that customization is important. We're just going to have to agree to disagree regarding its merits relative to usability and simplicity.

2) The build script can be used to build all configurations if parameters are specified, but it can also be used to build only one configuration. If you run it as

Code: Select all

sh full-build-809.sh atheros-2.6

only the atheros-2.6 configuration will be built. You can also tell it to only build the brcm-2.4 configuration in the same manner. See.. it let's me customize which versions to build

3) Why would I want to put "all my effort" into this? I agree, it's good practice to keep individual components as packages. However, I fail to see why this should be my top priority. In any case, as already noted, it's simply not possible to make a kernel patch part of a package. Also, there is no config file. The only configuration needed on top of configuring a wireless client interface is to specify "option client-bridge 1" in the relevant wifi-iface section in the /etc/config/wireless configuration file (which already exists). The hotplug script and the kernel module do the rest. If you're really interested, I'm happy to describe how it works and what files you need. If you'd like to re-package in some other form, be my guest... Gargoyle is GPL.

4) I think this goes back to (1). I want to be able to build everything with one single command. That means not having to run separate commands for checking out Gargoyle, checking out OpenWrt, patching, building etc... that's too much work. I might add that I'm not the only one who feels this is important: This is item #2 of The Joel Test, right after using version control.

[patpat]

1) ok
2) ok
3) I said if "I" where you... to me it's very important keeping a GUI 100% independent of any underlying process. I also understand your Client Bridge cannot be a package in the OpenWRT sense of the term, that's why I called a "package", we can call it a pseudo-package if you like, but the point is keeping it independent from the GUI. There could be people interested in you GUI that do not want to touch the OpenWRT kernel because (let say) your bridging patch affects performance... or people that want to use the the Client Bridge thing and do not want or cannot load a complete GUI because of memory constraints... You have 2 different modules here I hope they do not kill each other... I'd like to see the Client-Bridge thing tested independently from gargoyle...

4) I think Joel Test step 2) in a very dynamic environment is not a good Idea, sooner or later you get things broken without knowing where you are. You have this thread as an example.
I prefer a 3 steps approach "checking out + configuring + make" that gives much more control and if things get really stable I can always bundle up the tree steps in just one "buildall" script.