Google Summer of Code 2014

We are accepting applications! Apply for Google Summer Of Code 2014 now!
Deadline is 21 March at 19:00 UTC
​MacPorts at the GSoC website

This is the MacPorts Project’s page for ​Google Summer of Code.

Information about the past years can be found at SummerOfCodeArchive.

Applications for GSoC

Mentoring organizations can submit organization applications from 3 February at 19:00 UTC until 14 February at 19:00 UTC. The list of accepted organizations will be published 24 February 19:00 UTC. Students will be able to apply from 10 March 19:00 UTC until 21 March 19:00 UTC.

If you're interested in working with MacPorts for Google Summer of Code 2014, you don't have to wait until the application period for students starts. Introduce yourself on the macports-dev mailing list today or drop by in IRC by joining #macports on ​Freenode. See Ways to Contact Us for more information.

General info

For future reference you may check the ​Google Summer of Code website. The ​GSoC Student Guide is also worth reading and explains what GSoC is about and how it works in detail. We suggest you take a few minutes and read this guide.

For the official schedule and deadlines, consult the ​timeline.

For the MacPorts Project

We are eager to support and mentor students who want to gain experience by working on the MacPorts Project. We have many ideas for potential internship subjects, yet we are open to anything that is both interesting and relevant to MacPorts. If you have an idea of your own, feel free to contact us to discuss it.

MacPorts is written in the Tcl scripting language with some low-level parts implemented in C. Most students that have previously applied and successfully completed Google Summer of Code with us did not know Tcl when they applied. Feel free to apply if you don't know Tcl yet, especially if you're willing to learn and already know several scripting languages such as Python, Ruby, PHP or Perl.

The best way to apply is to first make contact with us, either by sending a mail to the mailing list, to potential mentors listed below, or to IRC member on #macports on ​Freenode. See also Ways to Contact Us for in-depth information on how to reach us.

What we expect from students for their applications

• Write your own abstract and proposal, copying text from this idea page is not enough.
• Show us that you fully understand your task and know what you want to do over the summer.
• At best, include a short weekly roadmap covering how you would work on the task.
• Please use our application template.

What you should do before handing in an application

• Get familiar with the MacPorts Project resources. Especially check out the code and ​read the guide.
• Read the ​Tcl Tutorial.
• Subscribe to the mailing list ​macports-dev if you do not already read it. Don't be too shy to post.
• Get in contact! Most important is to discuss your ideas with potential mentors via private email, the MacPorts development list, or the IRC channel before applying.

Mentors

The following committers have agreed to be mentors for GSoC 2014 (append @macports.org for email)

Name	Email	Area
Jeremy Lavergne	snc	Administrator
Clemens Lang	cal	Backup Administrator
Rainer Müller	raimue
Michael Dickens	michaelld	Mentor
Bradley Giesbrecht	pixilla	Backup Mentor to michaelld

Tasks

This is a list of some potential tasks that student GSoC members could undertake. These are just ideas, and while they express our current concerns, we are open to blue-sky projects related to MacPorts.

Please note that this list is absolutely not exclusive! If you have any idea about what you want to see improved in MacPorts, you are free to propose this as your own project. In any case, we recommend you talk to mentors before writing your application.

Core tasks

Dependency calculation using SAT solving

This task consists of implementing a new dependency engine for MacPorts. The current dependency engine works for everyday use, but it could be extended to support a number of features we would like to have, such as dependencies on variants (ticket:126), versioned dependencies, pre-computing a plan of action (and asking the user for confirmation), conflict resolution proposals and metapackages. Note that we don't expect you to accomplish all of these ideas in one GSoC – setting the base would already be a huge help.

This task requires understanding the dependency relations (required for fetching, building, configuring; static and dynamic linking; dependence at runtime).

Instead of re-inventing the wheel it might be helpful to use software available to solve the problem of dependency calculation, e.g. by implementing an interface to a ​Common Upgradeability Description Format-based SAT solver. Such a solver could generate an execution plan we could propose to the user and finally execute when confirmed. For this task, the MacPorts concept of variants needs to be transformed into a representation the SAT solvers will be able to optimize. If time permits, rolling back on failed updates can also be implemented. There is also a libCUDF​ port that might be helpful to look at.

• Difficulty: Challenging
• Languages: Tcl, C
• Potential mentors: cal

Phase out dependency on Xcode

MacPorts currently requires a full Xcode installation, even though a lot of ports will install just fine with the Command Line Tools package only. Since we also have a number of ports that need Xcode to build, we cannot completely remove the Xcode dependency. Your task would be to provide a way for maintainers to easily identify ports that depend on Xcode and mark them as such, so MacPorts can warn users without Xcode installed that a port they want to install needs the full Xcode package.

To achieve this, you can modify "trace mode", a DYLD_INSERT_LIBRARIES-based sandbox to track whether a port has accessed files belonging to the Xcode package. If it does, your modifications should cause a warning to be printed suggesting the port maintainers to add use_xcode yes to the Portfile (unless of course, it is already there). You should also implement an error message if a user without Xcode installed tries to install a port that has use_xcode yes set.

• Difficulty: Medium
• Languages: Tcl, C
• Potential mentors: cal

MacPorts port for self-management

The MacPorts port should be the source for updating a user’s MacPorts installation.

Currently the MacPorts port is used to build the .dmg installer for MacPorts that is used for the initial installation of MacPorts, and port uses the “selfupdate” mechanism for maintaining the MacPorts installation. The selfupdate mechanism is (at least not documented as such) not accessible through the MacPorts API and does not use the MacPorts mechanisms for maintaining ports.

• Difficulty: Challenging
• Languages: Tcl, C
• Potential mentors: TBD

Generating Portfiles

There are multiple tasks related to the generation of Portfiles. Some of these may not be enough work for a full summer project, so they could be combined for proposals freely when the applying student wants to.

Perl modules integration from CPAN

There has been an attempt to write a script for automatic generation of Portfiles from CPAN. This would simplify the maintenance of Perl modules in MacPorts. Revive this project and finish the script or rewrite it.

Resources:

• ​http://www.gentoo.org/proj/en/perl/g-cpan.xml
• ​http://search.cpan.org/~bingos/CPANPLUS-0.9001/bin/cpan2dist
• ​http://packages.debian.org/stable/dh-make-perl

• Difficulty: Easy to medium
• Languages: Perl, probably Tcl
• Potential mentors: TBD

Read packages from Python's PIP (pip2port)

MacPorts should be able to more readily install python packages from pip. We don't want to integrate the build/installation process of PIP, simply parse information or eggs it provides for various packages. This information will then be used to generate a Portfile, akin to cpan2port​.

There may be instances where MacPorts package names don't match up with pip’s. In this case, pip should be the authority and all improperly named MacPorts packages should be replaced by a renamed copy. Verbose automation of this step, akin to the portcheckup script, is ideal.

The portfile generator​ might be helpful.

• Difficulty: Medium
• Languages: Tcl, Python, C
• Potential mentors: snc

Read packages from other various package managers

As above with the pip2port proposal, except with other package managers, such as ​opam for ocaml packages, ​cabal for haskell, ​luarocks for lua, ​npm for node.js, and so on.

• Classification: Medium
• Languages: Tcl, C, OCaml, Haskell, Lua, Node.js, etc.
• Potential mentors: TBD

Generate Portfiles with auto-detection of build toolchain

To ease creation of new ports, the helper script ​portfile-gen is able to generated a Portfile stub by taking the name, version and possible a port group as input. This should be extended to handle more things automatically. Lots of options in a Portfile need to be figured out by the maintainer, although they could be extracted automatically from the source.

With just a URL to the tarball of a software, portfile-gen can usually automatically extract the name and the version from the filename. Furthermore, the master_sites and distfiles can be derived from the URL, with special handling for sites like sourceforge/gnu/github/etc. However, it should also be possible to specify this later and start portfile-gen with a pre-downloaded tarball. The checksums for the distfiles can be generated after fetching the tarball (portfile authors should be warned to verify these with upstream!) and even more information can be collected when extracting the tarball.

Different build systems usually have a unique way to be detected. For example, if a configure.ac or configure.in exists, but no configure, we need to run autoconf. If there is also a Makefile.am, but no Makefile.in this is using automake and we should better use autoreconf instead. If there is a CMakeLists.txt, we should include the cmake port group. If there is just a Makefile, but no configure, chances are high we can skip the configure phase with use_configure no.

There are a lot more of such heuristics similar the examples above. This tasks includes implementing a framework where more of these indicators and the resulting actions can be added.

The goal of this task is to create an easy-to-use Portfile generator that derives the basic information of a Portfile automatically. This should lower the amount of lines to be written by Portfile authors and lower the barrier for writing the first Portfile. If this is implemented with Tcl modules in mind, this could probably even go into base as a port new or port create command.

• Classification: Medium
• Languages: Tcl
• Potential mentors: raimue

Configuration and environment selftest

Add a command to check current setup for common pitfalls (e.g. stuff in /usr/local), inspired by Homebrew’s brew doctor functionality.

• Difficulty: Easy
• Languages: Tcl
• Potential mentors: larryv

Speed up trace mode

Trace mode is a library preloading-based sandbox used to hide files that a port does not depend on or that are not part of a standard system's installation (such as /usr/local). This can avoid problems due to incompatible user-installed software and avoid "automagic" dependencies and increase the reproducibility of builds.

Unfortunately, enabling trace mode adds a significant performance penalty to the build process. However, the trace mode code can certainly be optimized using appropriate cache data structures, such as a modified ​Trie. Your task would be to identify the performance bottle necks, draft appropriate caching data structures and implement them.

• Difficulty: Medium to Easy
• Programming languages: Tcl, C
• Potential mentors: cal

Improve startupitem code

MacPorts has the ability to automatically generate startup items for the current platform. For OS X, these are plist files for launchd which will be installed as /Library/LaunchDaemons/org.macports.*.plist. The current code would need a little care and could make use of options which have been added in recent releases of launchd.

Features that could be useful include (but are not limited to):

• Not using daemondo if the daemon works fine under launchd without it
• Ability to install multiple plists
• Support for LaunchAgents as well as LaunchDaemons
• Installing plists in ~/Library for non-root installs if the user wants
• only modify specific XML tags to avoid clobbering additions by user

• Difficulty: Easy
• Languages: Tcl, C
• Potential mentors: larryv

Reclaim disk space

Improve port clean to be able to delete distfiles for a specified version, and all distfiles not needed by currently installed versions of ports. In general, add an action for reclaiming disk space, which would delete old distfiles and archives and uninstall inactive ports (and anything else that would help). Implement heuristics to detect common hogs of disk space such as lots of old distfiles and inactive ports and periodically suggest running a cleanup command to users if such possibly unneeded files are detected.

• Difficulty: Easy
• Languages: Tcl, C
• Potential mentors: larryv

Parallel execution

When an action will run targets on multiple ports, run them in parallel when possible and sensible (requires tracking dependencies between both targets and ports and figuring out the maximum reasonable parallelism, e.g. several ports can fetch at once on a fast connection but you only want one 'make -j8' at a time).

• Difficulty: Challenging
• Languages: Tcl, C
• Potential mentors: TBD

Migrate muniversal into base (lipo merging)

Integrate the muniversal portgroup​ into base. Not just a direct copy-and-paste, but in a way that makes sense and preserves the way portfiles are expected to behave (which the current portgroup doesn't).

• Difficulty: Medium
• Languages: Tcl, C
• Potential mentors: TBD

Improve fetching from version control

Make cvs/svn/git/hg/bzr fetch types checkout into the distfiles dir and then export into the work dir, to avoid having to re-fetch after cleaning the work directory.

• Difficulty: Easy
• Languages: Tcl, C
• Potential mentors: larryv

Interactive port command

Write an interactive command-line tool that can be used instead of the non-interactive port(1). (The existing "interactive mode" of port(1) is actually just batch mode reading from stdin, and is not really interactive.) Factor out code used by both tools into a shared module.

An interactive tool would ask for user input to resolve many situations that cause port(1) to simply error out. For example, if you try to install a port and one of its dependencies conflicts with something already installed, it could ask if you want to deactivate the installed one and its dependents.

• Difficulty: Medium
• Languages: Tcl, C
• Potential mentors: TBD

Implement a Trac plugin to auto-assign tickets to port maintainers

Write a Trac plugin that uses an existing PostgreSQL database of ports and their maintainers (used for ​http://www.macports.org/ports.php) and automatically assigns new tickets that have the port field set to the maintainer(s) of the ports listed in the field.

• Difficulty: Easy
• Languages: Python, SQL
• Potential mentors: TBD

Already implemented. See #40987.

Ports

Qt 5

Create a port for Qt 5 (#37331) and try to fix issues in open tickets for Qt 4

• Difficulty: Medium
• Language: Tcl, C++
• Potential mentors: michaelld, pixilla

MinGW-w64

Create ports for the 64-bit MinGW cross-compiler and bring the 32-bit cross-compiler up to date. The task could include improvements to the crossgcc PortGroup.

• Difficulty: Medium
• Language: Tcl, C, C++
• Potential mentors: TBD

compatilibity of wxPerl and other wxWidgets/wxPython packages with wxWidgets 3.0

Try to patch wxPerl to make it compatible with wxWidgets 3.0 and try to fix other packages that still depend on wxWidgets/wxPython 2.8 to work with 3.0, so that we could finally get rid of GTK-based wxWidgets 2.8 in MacPorts. Those packages include grass, FileZilla, Code::Blocks, py-robotframework-ride, ... The changes should ideally be submitted upstream.

• Difficulty: Medium
• Language: Perl, Python, C++
• Potential mentors: TBD (mojca volunteers as a backup mentor)

Secondary tasks

Portfiles

Sweep through all Portfiles and look for useful opportunities to add more built-in Tcl functions that make Portfiles more (usefully) terse, powerful, flexible or easier to write. I'm sure there is an entirely family of helper functions yet to be written here. This might also include porting additional packages to MacPorts and cleaning up or removing obsolete ports.

• Classification: Medium
• Language: Tcl
• Potential mentors: larryv

Documentation and website

Improve MacPorts documentation, website and Trac system. Note that pure documentation proposals are not allowed by Google.

• Difficulty: Easy to difficult
• Languages: PHP, Python
• Potential mentors: larryv

Shell environment

Add support for providing basic and port-provided environmental services to users in the ~/.profile, ~/.cshrc, and ~/.xinitrc files, so that instead of manipulating the user's .profile to modify certain paths, the installer could append "source /opt/local/etc/bash.rc" to the end of a user's .profile file and that bash.rc would source all the files in /opt/local/etc/bash.d.

This task alone is most probably not enough for the whole Summer Of Code.

• Difficulty: Easy
• Potential mentors: raimue

Contacting us

There are several ways to contact us:

• Dropping a mail to the MacPorts-dev mailing list will get you most attention. Note that you have to be subscribed to the list in order to send mail to it. We recommend you create a filter matching the header line List-Id: macports-dev.lists.macosforge.org and sort all mails matching this filter into a separate folder. When sending inquiries about Google Summer of Code, we would welcome if you included "GSoC" in the subject of your mail.
• You can get quick feedback and less formal discussion by joining the #macports channel on the ​Freenode IRC network. You'll need an IRC client to do so – ​Colloquy is a popular choice on OS X. Please note that due to timezones and day jobs you might not receive an answer right away. Most users will read your messages when they return and answer as soon as they can. Be prepared to wait a few hours.
• Feel free to contact any potential mentor via email directly. You can get the email address by appending @macports.org to the handle listed in #Mentors above.

In general, don't hesitate to contact us – we're here to help you and eager to mentor motivated students in this year's GSoC!