wiki:SummerOfCode

Google Summer of Code 2018

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 4 January until 23 January at 17:00 UTC. The list of accepted organizations will be published 12 February 16:00 UTC. Students will be able to apply from 12 March until 27 March 16:00 UTC.

If you're interested in working with MacPorts for Google Summer of Code 2018, 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.

Proposal Guidelines

Submit your proposal early: early submissions get more attention from developers for the simple fact that they have more time to dedicate to reading them. The more people see it, the more it'll get known.

Do not leave it all to the last minute: Make sure you send your application before the final rush. Also, note that the applications submitted very late will get the least attention from mentors, so you may get a low vote because of that.

Keep it simple: we don't need a 10-page essay on the project and on you. You just need to be concise and precise.

Know what you are talking about: the last thing we need is for students to submit ideas that cannot be accomplished realistically or ideas that aren't even remotely related to MacPorts or the project. If your idea is unusual, be sure to explain why you have chosen MacPorts as the best place for the project.

About Us

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 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.

Students

For the students and projects in the previous editions of GSoC with MacPorts, see SummerOfCodeArchive.

Projects

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.

Ideas

Collect build statistics

Go through the history of builds and collect per-port statistics & success matrix:

  • whether the current version of port built on each particular OS/arch
  • when was the last time the port built on that OS/arch
  • links to all builds
  • list of installed files, differences in installed files on different OS versions
  • perhaps include some basic functionality to allow checking for build reproducibility
  • what is the latest version of port (in case it's already outdated), ...

It would be nice to get a decent website for each port to get a quick overview of the port status & health across different OSes. (Part of statistics collection could also be implemented as an extension to Buildbot or Buildbot setup.)

  • Difficulty: Easy to medium
  • Languages: JSON, HTML, Python or any scripting language
  • Potential mentors: mojca

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
  • Support startupitems in standalone binary packages (currently a brutal hack is used to include daemondo in such packages, see #43648)

It would be great to write some shorthand in a portfile that builds an XML launchd plist.

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

Managing and Fixing Qt Versions

Fix issues in open tickets for Qt 3, Qt 4, and Qt 5, in particular allowing for concurrent installation of the various Qt versions. There are around 50 outstanding tickets for the various Qt versions, many of which would be resolved by installing all or enough of Qt* into the main install prefix subdirectories. Some involve patching and testing on multiple OSs. Some are probably invalid but need to be tested to determine validity. The end goal for this project is to allowing for concurrent installation of the various Qt versions, and then verifying and resolving as many issues as possible that weren't resolved by the concurrent changes. Requires knowledge of Portfile programming (Tcl), Qt programming (primarily C++), and Qt makefile programming (QMake); other programming knowledge that would be useful include shell (e.g., bash) and C.

  • Difficulty: Medium to Hard
  • Languages: Tcl, C++, QMake
  • Potential mentors: michaelld

Implement fakeroot functionality

Currently, MacPorts uses root privileges in the destroot phase. That should be replaced by a system that runs as the macports user but intercepts all operations that would require root privileges (chown/chmod/etc.) and record the resulting permissions in a database.

The existing functionality of trace mode in darwintracelib1.0 could be leveraged for this task.

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

Generating Portfiles

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

i. 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:

  • Difficulty: Easy to medium
  • Languages: Perl, probably Tcl
  • Potential mentors: pixilla
ii. Read packages from various package managers

As with the cpan2port proposal above, and with the previous pypi2port GSoC entry, except with other various 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: pixilla

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

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 bottlenecks, draft appropriate caching data structures and implement them.

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

Auto-detection of build dependencies

When creating a new portfile one of the problems is always the specification of the complete (and preferably minimal) list of build dependencies, especially when one starts with a complete install where most dependencies are already available.

It is possible to invert the trace mode logic so that it detects all files a configure and/or build process accesses, in ${prefix} but outside of the port's build directory. This information can then be used to generate a dependency tree and information from the registry can then be used to simplify that tree so that it only lists direct dependencies. Can be combined with the above project. Consult mentor.

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

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. "fetch.type svn" is inefficient in that it checks out a new working copy every time, directly to the work area. That would be like a normal port downloading the distfile every time. Instead, we should check out a working copy to that port's distpath, and then in the extract phase we should svn export it to the work area.

Some checks will be needed in the fetch phase to ensure that an existing working copy:

  • has no modifications: check svn status. Ideally, we would try to clean up the working copy, for example by svn revert-ing modified or added or deleted files, and then in a second svn status run, delete any unversioned files. But it's already an improvement if we just discard the working copy if svn status --ignore-externals produces any output.
  • is from the right URL: check svn info: check if the "URL" is the one we want. If not, check that the "Repository Root" is a substring of the repository we want. If yes, try to svn switch to the URL and revision we want; if not, discard the working copy.
  • Difficulty: Easy
  • Languages: Tcl, C, bash
  • Contact: larryv

More Ideas/Hints for your own ideas

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.

  • Difficulty: Easy
  • Potential mentors: raimue

Bump version and checksum of existing port

Homebrew has brew bump-formula-pr. Such functionality saves a lot of work when updating many ports. Bumping ports using PortGroup like GitHub and bitbucket should also be supported. Existing revision should be reset or removed interactively. A suggested commit message for the update should be shown.

Use cases (pseudo commands):

  • port bump [[portname | pseudo-portname | port-expressions | port-url]] bumps checksums only
  • port bump [[portname | pseudo-portname | port-expressions | port-url]] @<version> bumps version and checksums
  • port bump --livecheck [[portname | pseudo-portname | port-expressions | port-url]] bumps both with livecheck result if ${version} == ${livecheck.version}

See #53851 for more details.

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

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 .pkg 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

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

App portgoup

Enhance the launching of GUI apps packaged by MacPorts:

  • Fix app icon bouncing on Dock after app launched (#40110)
  • Support multiple apps per port (#41681)
  • Difficulty: Easy
  • Languages: TCL, XML
  • Potential mentors: TBD

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

MacPorts statistics

Enhance collection and reporting of inventory of ports installed by participating users: StatisticsIdeas

  • Difficulty: Medium
  • Language: TBD
  • Potential mentors: TBD

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.macports.org and sort all the emails 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 for 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!

Admins

Append @macports.org for email.

Name Email Area
Jackson Isaac ijackson Backup Admin
Umesh Singla umeshksingla Administrator

Mentors

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

Name Email Area
Jeremy Huddleston jeremyhu Mentor
Michael Dickens michaelld Mentor
Bradley Giesbrecht pixilla Mentor
Mojca Miklavec mojca Mentor
Clemens Lang cal Mentor
Jackson Isaac ijackson Mentor
Eitan Adler grimreaper? Mentor
Last modified 40 hours ago Last modified on Feb 17, 2018, 8:45:35 PM