Package Builder was established out of the need to have prebuilt packages available for playground testing and development on FreeBSD's armv6 platform. Since armv6 is not a Tier 1 platform, it doesn't receive same treatment as Tier 1 platforms, such as regurlary prebuilt packages. Therefore I decided to build a staging server to build packages on the fly whenever needed, since compiling them on the Pi itself was just taking too long.
Currently, the arvm6 platform is supported. I may be adding others as well in the future.
As I said, I established this due to the lack of prebuilt packages. If armv6 becomes Tier 1 and gets official packages, this service is very likely to be obsoleted and shutdown."
Currently I build packages targeted at the FreeBSD 10 release train. I'm looking forward to support HEAD along the lines eventually as well.
I use a build infrastructure based upon poudriere.
Not at this time. I'm just using the sane port Makefile defaults. If there is a demand, I may be adding a feature like this eventually.
Beware, no! That would just take aaaaages to complete! I use a host cross-compiler on an Intel x86_64 8-way Xeon box. This allows to build the packages at decent and reasonable speeds. The main point for building this platform to get a speed up if I need a package. It wouldn't give me anything to wait for hours and hours ...
It's an 8-way Xeon with 32 GiB of RAM and 1 TiB SSD storage. Poudriere is configured to use a memory file system to stage all files in RAM. That's the best I can do. Granted, there's surely more powerful gear out in the wild ;-)
Don't forget that doing a cross-compile is not the fastest of all things. While a host cross-compiler is almost as fast than a native compiler, it stil takes some time, because some of the build stages, like autoconf for example, need to be run through qemu. Also, if a port fails, a second attempt is made to compile it via full emulation instead of using the cross-compiler, and this then happens to be *really*really* slow!
Well, either they're not arvm6 compatible, or they can't be compiled with the host cross-compiler (yet). There is a mech to retry failed builds in a fully virtualized qemu environment to at least provide packages that would build properly on the native target compiler. If you configure both a xfbsd..... a vfbsd..... repository at the same time, you can have a mixed setup from both repositories, where the later one is filling the gap of the first. Here's an example on how this turns out on a real system (note the different repository names):
# pkg install curl Updating phnpkg-vfbsd10armv6-current repository catalogue... Fetching meta.txz: 100% 820 B 0.8kB/s 00:01 Fetching packagesite.txz: 100% 11 KiB 11.0kB/s 00:01 Processing entries: 100% phnpkg-vfbsd10armv6-current repository update completed. 37 packages processed. Updating phnpkg-xfbsd10armv6-current repository catalogue... phnpkg-xfbsd10armv6-current repository is up-to-date. The following 2 package(s) will be affected (of 0 checked): New packages to be INSTALLED: curl: 7.47.0 [phnpkg-vfbsd10armv6-current] ca_root_nss: 3.22 [phnpkg-xfbsd10armv6-current] The process will require 5 MiB more space. 2 MiB to be downloaded. Proceed with this action? [y/N]:
For one, this goes together with the package repository naming, which denotes wether builds are done using the cross-compiler, or within a VM. The latter is done when a port fails to build using the cross-compiler. Since repositories cannot be easily merged, a combination of two repositories is to be configured. This way, you can selected from which repository to install a package from, while still getting best of both worlds.
Some copyright holders place redistribution restrictions on the software. In order to comply with the licensing terms, such software is not available for build selection.
Packages are never rebuilt unless the upstream source changes. New packages added to the system are built automatically, the queue is constantly polled.
For one reason, because this is a gap-filler and for playing around with the Pi, not all of the twenty gazillion ports are needed. For the other reason, I simply don't own enough hardware capabilities to sustain a complete build process for just all ports there are. Going for the current approach allows me to grow and provide just what's needed. It's very pragmatic ;-)
A snapshot of the current ports tree is taken once a month and used to build packages from it. This happens automatically so I don't need to take care for this. Cron is King!
Likely not, as I don't have the resources to sustain fully nightly rebuilds.
I keep all past package trees for as long as I can sustain the disk space requirements. When it comes to what is actively maintained: Only the past three monthly snapshots taken are maintained. Port snapshots older than three months won't be maintained anymore, which means, no new port releases there.
You can do so, if you want. I do however provide a "current" packages tree, which always resolves to the most recent built. If you go for this rolling release, you'll always get the most recent packages available. The "recent" packages tree also resolves the URI according to pkg's "ABI" resolver, so if you configure this, it'll stay the same, no matter if you use FreeBSD 10 or FreeBSD 11.
It's actually easy to understand: the fbsdNN-aaaa prefix just denotes, which FreeBSD™ major release and target architecture the repository is intended for. Curently, there is only armv6, but the structure allows for easy addition of other non-Tier 1 architectures in the future. If the repository is prefixed with either x or v character, it simply means that the packages where built using a host cross-compiler or a fully virtualized within qemu respectively. The pMM_YYYY suffix just denotes as per which month and year the ports snapshot was made.
Me, myself and I, with my personal hardware and private time, using privately owned resources.
Yes. I have no intention to charge for it. I run this, because it's fun, it has a practical use to myself, and maybe others can benefit from it as well. I do however reserve the rights to cease this service if funding would become an issue, or if FreeBSD project is gonna release official packages.
Nothing serious, only a bandwidth cap of 5 mbps, just to stay within limits and keep costs down.
Maybe one day, but for now this is just a small thing, yet some "me too", made primarily for myself and some friends. Let's keep it on this level at the time. On the other hand, if someone really insists in helping or donating, send a message to hostmaster @T phunsites -dot- net.
The website uses Phalcon PHP framework, bootstrap, some jquery and NoSQL in the backend. I kept it simple and small for this purpose, with some speed considerations in mind.
Besides poudriere, which already does a great job to automate the build process itself, I use a combination of shell and perl scripts to handle some of the backend tasks, like port snapshots, queue monitoring and auto-dispatching. Additionally there's a bit of SSH and rsync trickery to deploy the package trees from the build server to the web frontend.
Yeah, I know. The framework does support it, and in fact everything's there already ready to use. But translations need to be done, and honestly, I didn't want to take the extra effort yet. Right, what was that again about "help" ;-)
Thanks for being honest. Since I'm not a web designer I can perfectly live with it. Feel free to provide a better design.
Sources are going to be available eventually. I have no reason to keep it closed and once I'm done cleaning up some leftovers, the source will be available for download at this site. Source will be licensed under the terms of the BSD license.
Not for as long as you use the proper package trees. In other words: If you use the pre-generated config snippets as provided from the main site, the generator will make sure, that the xfbsd.... (cross-compiled ports) repository will always have a higher priority then the vfbsd.... (compiled within virtual machine) repository. And it's important to mix-and-match only the corresponding counterparts of the same branch, i.e.
Because the actual build process runs on another machine. Some information is pushed forward to the web frontend in realtime, while the poudriere build stats are only updated when the build is complete.
... walk into Mordor? ... route to DEFAULT? ... write silly FAQs? ... kill Han Solo? ... What? WHAT ??? Really!? Oh no, they killed Han Solo .... nooooooooooo! But hey, who cares, because Star Trek is awesome again! Just kidding ;-)