Email: MailTo(gabor@FreeBSD.org)

I am a Hungarian student of 18 interested in FreeBSD and in open source in general. I've been using FreeBSD in desktop for a long time and I've also administering a small FreeBSD server, that provides web, e-mail, etc. hosting. As a result I got experienced as a desktop user and as an administrator. Besides, I started to work on porting softwares and sending improvements for existing ports. Currently, I maintain these [http://people.freebsd.org/~fenner/portsurvey/gkovesdan@t-hosting.hu.html ports].

As a SoC student, my goal is to make some enhancements and implement some new features to make the Ports Collection even better, more efficient, and easier to use.

There are some i386 binary ports. This means that the given application is free, but closed source. These ports fetch the compiled i386 binaries for FreeBSD from the vendor's site and install them appropriately. This behavior introduces a deficiency. Some of these ports are enabled only for i386 architecture, but some of them are enabled for amd64 and ia64 as well, because these architectures can run these binaries in compatibility mode. The compatibility layer is not necessarily installed, however. In the first case, amd64 and ia64 users cannot use these ports even if they have the i386 compatibility layer installed, but in the second case the port can be installed even if the compatibility layer is not installed. This leads us to unusable installed software. As a solution, a check should be introduced, whether the compatibility layer is available or not, and the affected ports should be modified accordingly.

Status: Done. Committed to CVS.

According to the Porter's Handbook, ports should always respect these flags, but there are ports that do not comply with this. I am going to test ports in a tinderbox if they are respective or not, and patch the weird ones. Firstly, I wanted to work on ICC support, but I can't do that, because I don't have a commercial Intel license, so I can't publish a derivative work. At the end, I decided to choose this task, since it can help us going towards the ICC support.

Status: Haven't started yet

The FreeBSD jail facility provides the ability to partition the operating system while keeping the UNIX filesystem model. This is useful for imprisoning processes or providing virtual server hosting. More people asked the feature in the past to support installing ports into another environment. This other environment might be a jail environment or a standalone installation mounted elsewhere than /. This would be very useful for maintaining small jails, the ports tree would not need to be copied into the jail any more. Another good example is populating a small hard disk with softwares. The building process can cost a lot of disk space (even 2GB in some cases) and this make it impossible to build some software for an old computer with small disk. Another good advantage is being able to install the same port on one system with different install-time options or to install conflicting ports (,ports that install the same file in the same location and overrides each others files).

See the [“DESTDIR”] page for more info.

Status: Patches available: [http://gabor.t-hosting.hu/patches/destdir_mk_6.diff 1] [http://gabor.t-hosting.hu/patches/destdir_tools.diff 2] [http://gabor.t-hosting.hu/patches/destdir_ports.diff 3]

We have both ECHO_CMD and ECHO_MSG in bsd.port.mk. ECHO_CMD is the echo shell built-in at default, while ECHO_MSG is ECHO_CMD at the default, but they are for different purposes. ECHO_MSG is for printing output, which is relevant for the end-user, while ECHO_CMD is mostly for internal use, e.g. command-line pipelining, like @${ECHO_CMD} “@cwd ${PREFIX}” » ${TMPPLIST}. Accordingly, one might want to override ECHO_MSG so that one get a colorful output, or use a wrapper for these messages. Currently, in bsd.port.mk ECHO_CMD is also used for printing user output. The attached patch substitutes these occurrences to ECHO_MSG.

Status: [http://www.freebsd.org/cgi/query-pr.cgi?pr=100556 Patch] available

A basic support for building debugging binaries is very needy. Some individual ports have a WITH_DEBUG option, which adds some specific items to build binaries for debugging purposes, but there are general things that are alway useful that, e.g. the -g gcc flag and installing binaries not stripped. This change is to introduce these additiond, individual ports still could/should add their own specific stuff for debugging.

Status: [http://www.freebsd.org/cgi/query-pr.cgi?pr=100939 Patch] available

Fetching the source distributions and patch files are only a small part of the build process of a port, but the code that implements this fetching takes a lot of space in the bsd.port.mk code, making it messy and hard to read. There was a discussion about this on the mailing list a long ago, but nobody has taken care to clean up the code.

Status: Work in progress

The whole FreeBSD base system can be cross-compiled, but the ports infrastructure cannot. Implementing cross-compiling for the Ports Collection is pretty complicated and difficult, because the cross-compiled versions of the necessary libraries and ports must also be present, while the base system is built as a whole part and no external dependencies are required. On amd64/ia64 platforms, there is a compatibility layer that allows us to run i386 binaries, so in this case it would be a bit easier to accomplish. There are also a lot of ports that are only for i386, so it would be nice to implement cross-compiling at least on amd64/ia64 for i386. Accordingly, the number of usable ports on amd64/ia64 would dramatically grow. Actually, there is a way to cross-compile ports on amd64/ia64 platform for i386. This method is making a 32-bit jail environment. This way needs too much time, too much disk space and too much user interaction. A better method should be worked out. NetBSD's cross-toolchain might be a good starting point.

Status: Haven't started yet

Every port has a packing list (plist), which contains the list of the installed files of that port. It is necessary for a clean removal. This plist is stored in the port Makefile or in a separate pkg-plist file for every port and should be generated by the porter. This tool would make it easier for porters to generate those plist files.

Status: Haven't started yet