Package Development Questions
Well, color me frustrated. I took the hints, jimp handed out about what needs to change in havp to work on nanobsd, and download the 1.2.3 developer ISO to install in a VM to work on this. It won't even boot! (I have posted two messages elsewhere, one in the development forum and one in the Installation forum), and no reply from any devs. FWIW, this breakage dates back to at least September 1st, since I have tried 3 different snapshots and and they all fail the exact same way. I'm sure the devs are busy and all, but it is hard to believe that no one has noticed (or cared) that this has been borked for almost two months. Trying to keep a good attitude here, but wow…
Well the devs don't use the dev isos, oddly enough :-)
There was a reason for the breakage, but I don't recall what it was. I thought the dev iso builds were shut down because of it.
Augh!!! Is this described anywhere? So… how am I supposed to do this then?
You don't need a dev iso for package work. For testing I do it live on a test box, for working on the repo I use msysgit/gitbash. I also do work from various freebsd boxes.
There is an article on the developer's wiki about basic package coding, but I doubt it would help in your case.
I have a whole set of VMs setup in VirtualBox for different kinds of testing and such, but not everyone would want to go through all that trouble.
When testing the nano packages I actually setup my own custom package repo on my website and then pointed my alix there so I didn't have to check every little test commit into the git repo, but again, that's me. :)
I guess there is a knowledge infrastructure problem here. If I knew the right questions to ask, this would be a lot simpler :) The packages are in a certain format. Wherever the repo is, I guess it doesn't have to be a pfsense (or even BSD) system? This is frustrating for me, since I am an experienced software engineer, but I feel like someone who doesn't even know how to get into the car, much less drive it - once I get this done once, it will be much, much easier.
Yeah it can be a bit of a drag at first.
I'm going to split this conversation into a new thread, then post more info.
thanks, much appreciated. i really like pfsense, and would like to be able to give back, so to speak…
It's really not for the faint of heart, but if you really want to know all the gory details, here goes:
The first thing you'll need is a copy of the package repository (repo) on a system you control, not a pfSense box, but somewhere you can view/edit files easily.
Visit the git repo for packages here:
You can use whichever git front-end or software you want, really, the end result should be similar. Once you clone the git repo (From the URL given on the site above, likely http://gitweb.pfsense.org/pfsense-packages/mainline.git ) you will have all of the files for all packages on your system, and you can look at the code and see how things are put together.
From there you can make changes and then make a diff to submit to a developer (such as myself) or more likely to a ticket on http://redmine.pfsense.org.
As for testing the packages, there are instructions at http://doc.pfsense.org/index.php/Developing_Packages which explain how to setup a custom package repo URL on a site you control. Doesn't have to be anything fancy, just needs to serve PHP and I think it needs the XML extensions for PHP, but those are pretty standard. Once you have your own package repo setup you can copy the files there which you checked out from git, into the packages/ folder. Then edit /etc/inc/globals.inc on your test pfSense box and change
Adding to the fun, if your test box is a nano install (which in this case it should be) before you can edit any file on the box directly you have to change to read/write mode by running:
and then back to ro at the end:
Another problem is that the xml package files from the git repo all (or mostly) have URLs which point to a pfsense URL for downloading the additional package files. So for the package you are testing you'll have to edit its main .xml file and adjust the paths to point to your own site instead. (And remember to change them back before making/submitting a patch!)
Now you have a copy of the git repo, your own package repo url, and a box pointing there, you can start hacking away at the source files. (If you have shell access to the web server and it has git installed, you can combine a few steps and just check the repo out directly…)
That's essentially how I do most of my more complex package work. Easier stuff I just check fixes into the repo directly and hope it works. ;-)
One of these days I need to update the doc wiki article on packages with a more coherent version of this stuff. I may be leaving something out, too, that I take for granted but others might not know.