Differences between revisions 17 and 18
Revision 17 as of 2011-03-15 15:04:34
Size: 14856
Comment:
Revision 18 as of 2011-03-20 17:30:45
Size: 16958
Editor: ?MarcBrockschmidt
Comment:
Deletions are marked like this. Additions are marked like this.
Line 28: Line 28:
==== Developer Package Repositories ====
 * '''Mentor''': Marc Brockschmidt
 * '''Summary''': Create a system allowing developers to publish and auto-build temporary, non-official packages
 * '''Required skills''':
  * Perl
  * (A wee bit of) webdesign skills
 * '''Description''':
   Analogously to https://launchpad.net/ubuntu/+ppas, we want allow DDs (and perhaps DMs?) to publish their experimental,
   non-official packages on a Debian platform. This system should allow maintainers to upload a package just as
   ftp-master.debian.org: At least source and Arch: all packages need to be provided by the maintainer, autobuilding and
   distribution is provided by the system.

   This project has four parts:
     1. Extend wanna-build to allow storing for certain package repository-specific information (mainly sources.list entries defining where the source package and build-deps are to be found, and an upload target)
     2. Extend buildd to use this information and set up the build environment. To not pollute the environment, this should use schroots ability to use snapshots of a source environment for building, then throwing away this snapshot. This needs to allow auto-signing and uploading of built packages to the right archive and needs to notify the uploader of possible build failures.
     3. Set up the actual archive: Uploads need to be processed, wanna-build needs to be informed about new source packages, apt-able directory structures need to be managed, the archives should be autosigned with the system's key.
     4. Provide a web interface allowing maintainers to set up an repository, specifying who (identified by GPG keys?) is allowed to configure it and upload packages. Configuration includes the base distribution(s) (stable, testing, sid or any combination) and possibly other personal repositories that are needed for dependencies.
     For every repository, a reasonable web page to provide information to users should be created from this. It should clearly state who is responsible for the packages and what other repositories are needed.

The main page is at SummerOfCode2011. This page contains ideas and proposals and information for applying.

Proposals

Example If you want to add your idea proposal, create a new page as a sub-page of SummerOfCode2011 by accessing its intended URL directly, select the "?SummerOfCode/ProposalTemplate" template and link to that page from here.

Debian installer

Hardware porting

Cross-compilation and cross-virtualisation, cross-cloud with Eucalyptus

  • Mentor: Steffen Moeller; seeking help/substitute from pkg-fso and/or Debian-Embedded

  • Summary: Smoothen the experience to develop cross platforms

  • Required skills:

    • above average intellect
    • good understanding of Debian boot processes
    • kernel configuration and compilation
    • fluent reader and writer of English
  • Description: Debian is proud of its achievement to provide mostly functionally identical compute environments for all the most common platforms. And that should also be available for virtual machines, i.e. one can emulate an ARM processor on an Intel machine and start an ARM-image on it. Well, at least in theory. In practice, there is then the kernel expecting an initrd to feature the ext2 module which then is not available when performing the emulation or something like it -- all the things that the native developers may not have thought about and that too few people test. A student assigned to this project shall identify the most common processes for cross-platform development. Problems shall be identified, triaged and fixed to the degree that this is possible. Of particular importance is the writing about the experiences made for future reference and the improvement on existing documentation. Particular attention shall be given to the ARM platform that is of particular attraction for mobile computing. If time permits, i.e. if past issues have been resolved, then the integration of ARM images with an installation of the cloud environment Eucalyptus on amd64 or i686 shall be addressed. This could all be of enormous value for cross-platform software development. The cross-building is of particular interest alone, e.g. for compiling KDE or the Kernel itself, which is just too much for many embedded environments.

Infrastructure

Developer Package Repositories

  • Mentor: Marc Brockschmidt

  • Summary: Create a system allowing developers to publish and auto-build temporary, non-official packages

  • Required skills:

    • Perl
    • (A wee bit of) webdesign skills
  • Description:

    • Analogously to https://launchpad.net/ubuntu/+ppas, we want allow DDs (and perhaps DMs?) to publish their experimental, non-official packages on a Debian platform. This system should allow maintainers to upload a package just as ftp-master.debian.org: At least source and Arch: all packages need to be provided by the maintainer, autobuilding and distribution is provided by the system. This project has four parts:

      1. Extend wanna-build to allow storing for certain package repository-specific information (mainly sources.list entries defining where the source package and build-deps are to be found, and an upload target)
      2. Extend buildd to use this information and set up the build environment. To not pollute the environment, this should use schroots ability to use snapshots of a source environment for building, then throwing away this snapshot. This needs to allow auto-signing and uploading of built packages to the right archive and needs to notify the uploader of possible build failures.
      3. Set up the actual archive: Uploads need to be processed, wanna-build needs to be informed about new source packages, apt-able directory structures need to be managed, the archives should be autosigned with the system's key.
      4. Provide a web interface allowing maintainers to set up an repository, specifying who (identified by GPG keys?) is allowed to configure it and upload packages. Configuration includes the base distribution(s) (stable, testing, sid or any combination) and possibly other personal repositories that are needed for dependencies. For every repository, a reasonable web page to provide information to users should be created from this. It should clearly state who is responsible for the packages and what other repositories are needed.

APT/dpkg

declarative diversions

  • Mentor: Steve Langasek; supported by Raphaël Hertzog for dpkg maintainer review and sign-off

  • Summary: implement support for declarative diversions in dpkg, to obsolete manual calls to dpkg-divert in maintainer scripts

  • Required skills:

    • C programming
    • ability to communicate clearly in written English
  • Description: The dpkg package manager allows packages to redirect ("divert") files belonging to one package to replace them with their own implementation. This is currently done by invoking a command, dpkg-divert, from package maintainer scripts, which is fragile and error prone; most references to dpkg-divert in the maintainer scripts of a typical system today are attempts to fix up past incorrect uses of dpkg-divert.
    The dpkg-divert command should be replaced with a new control file with a declarative syntax which dpkg will parse and process directly as part of the package unpack and removal phases, eliminating the problems resulting from non-atomic handling of diversions.
    Any solution to this problem must include documentation on correct use of the new feature and provide a transition path for packages using the existing non-declarative method of diverting files.

  • Applications:

Bug tracking

linux-2.6 Packaging

packages.debian.org

Packaging and upgrades

Jigsaw

Java packages

  • Mentor: SteffenMoeller

  • Summary: Further develop techniques for packaging Java libraries for Debian, describe and apply them

  • Required skills:

    • Good Java skills
      • ant
      • maven
    • Good in Debian packaging
    • Motivated to get a few more science applications in
  • Description: Java has made quite an impact on software development in Bioinformatics. Taverna [1], Artemis [2], Jalview [3] or OBO-EDIT [4] are all depending on a plethora of jar files. And those jars are then shipping with the source code. This effort shall describe existing concepts for package Java applications with Debian and develop them further to help with e.g. version dependencies to unversioned .jar fies and the parallel installation of multiple versions. The project will help Debian in many ways. The most obvious way may be completing a set of libraries used in Open Source developments. But also a better guidance of developers towards Java packages will be much appreciated and will help attracing more maintainers to the distribution. Finally, the effort also helps the development of those applications since the effort to install the infrastructure is reduced.

Science

Streamline the preparation of BOINC projects

  • Mentor: SteffenMoeller

  • Summary: Further develop the boinc-server-maker package, complete the turorial and apply it all for virtual drug screening

  • Required skills:

    • good reading and writing skills
    • strong interest in scientific computing
  • Description: BOINC stands for the Berkeley Open Infrastructure for Network Computing. Debian offers a readily usable package for the BOINC client since several years. Co-maintained with Ubuntu developers the package directly reaches tens of thousands registered installations and as such represents as considerable contribution to the volunteer computing community. The recent Google Code-In project seeded an effort to also help a larger adoption of the server side of BOINC for the distribution [1,2]. A thus reduced setup time for BOINC projects shall then foster the adoption of the technology for smaller environments and smaller problems. And a clearly paved technology shall further help to allow grant writers to focus more on the application side, which will this way also help the larger projects.

    • Challenges:

      • Show and document that the boinc-server-maker package of Debian is fully compatible with the VMware setup that BOINC provides itself.
      • Address the problem of MySQL schema changes between versions by using the tools BOINC provides.
      • Prepare a template package (e.g. from the examples) for application specific boinc-server packages. The boinc-server-maker package shall be a build dependency for that package.
      • Get as far as you can in preparing one or multiple Debian packages for in silico screening of molecular compounds with autodock [4].
    • Aims: This GSoC project shall take all the tears and fears from preparing novel BOINC projects. This shall take half of the time and determines the interim report. Then be as good as you can for the application on molecular docking. This may literally safe lives.

    • References:

      1. http://wiki.debian.org/BOINC/Server

      2. http://packages.debian.org/experimental/boinc-server-maker

      3. http://boinc.berkeley.edu/trac/wiki/QuickStart

      4. http://autodock.scripps.edu

  • Applications:

Genetic Cloning with Debian

  • Mentor: SteffenMoeller

  • Summary: Improve the interplay of several tools for preclinical research and write respective tutorials

  • Required skills:

    • good reading and writing skills
    • strong interest in computational biology and genetics
    • Perl
    • wxWindows
  • Description: Several routine tasks in preclinical research are a continuous nuisance with Open Source tools on any OS. Debian has an edge since it offers a series of applications that address most of those routine issues. This availability the upstream developers had not anticipated by the developers of those contributing tools. Also, some tools need a bit of maintenance to update their URLs.

    • Challenges:

      • Update URLs e.g. for Ensembl for PerlPrimer

      • Write a tutorial for cloning with GENtle

      • Improve GENtle

        • do not only rely on ClustalW but alternatively also on other alignment tools of Debian

        • prepare for some eye candy, e.g.use of svg icons, the use of standard icon collections and their extension by own work
        • allow GENtle to run PerlPrimer

        • extend usability as suggested here.

      • Improve PerlPrimer

        • Find way to integrate newer technologies, especially for quantitative PCR
        • again, better eye candy and usability
    • Aims: Strategically, this project reminds ourselves that Debian is more than the packaging of readily available software. It is also about gluing components together or to prepare for it. The most tangible result is the time saving for all the molecular biologists out there using GENtle, PerlPrimer and friends. The tutorial introducing to these tools will attract more to our distribution and be of high educational value.

  • Applications:

DebianPureBlends

Improve portals of Debian Pure Blends

  • Mentor: SteffenMoeller

  • Summary: Establish and evaluate the collaboration on packaging non-redistributable source-accessible software

  • Required skills:

    • good reading and writing skills
    • source code management with svn and git
    • web programming
    • Debian packaging
  • Background: As a community we share our interest in Debian as a core IT infrastructures. But computing is also about having all the tools at one's disposal to help solving your daily routine at work - with applications that may aim at a less general audience. The sub-communities of Debian (Blends [4,5]) all have their particular portal-like home page to give the distribution a particular flavour, i.e. for pre- and post-clinical research and practice management (Debian Med [6]), various sorts of molecular or astronomical sciences (Debian Science [7]) and others. Our users report that those pages are too much aiming at ourselves who we are packaging the software and not enough at those who would need to use it. They do not find us and if so, they do not feel motivated enough to understand it. Much of the pages are created by an abstract description of the packages we provide. Many other parts are on wiki.debian.org or www.debian.org. We now need someone with an unbiased mind to work through our site and come up with a way to present more clearly what a particular blend is all about. The developed infrastructure would then be offered to all blends to use. Description of work: The project shall start with an analysis of strengths and weaknesses of the current system. Missing features for our users shall be identified and an implementation plan developed. Main issues are

    • simplification, i.e. a complete overhaul the auto-generated home pages of the blends (like that of Debian Med [6])
    • user feedback and discussion
    • problem-oriented education - by users for users
    The student shall also experiment with a new kind of package package, i.e. those that only exist to help the local compilation of software but are not available as binaries: "not-even-source distributions" or "collaborations between package maintainers". Quite few software developers offer the download of source code and accept patches to it - but they do not allow the redistribution of the source and/or the binaries. The community of such projects is often large, like e.g. for Rosetta [1], NAMD [2], VMD [3]. Especially for Rosetta, the compilation of software associated to the core of Rosetta is common scientific practice. This may also involve complete recompilations. And without the right preparation of libraries, all in the right version, the compilation will fail or the scientific results not be accurate. The project shall strengthen the Debian community to provide a platform to exchange insights concerning the way that those complex software suites shall be built. While reworking the current infrastructure [4] of Debian Blends [5], the means support such an open exchange on those Debian-tailored build instructions shall be developed.
    1. http://www.rosettacommons.org/

    2. http://www.ks.uiuc.edu/Research/namd/

    3. http://www.ks.uiuc.edu/Research/vmd/

    4. http://svn.debian.org/svn/blends/

    5. http://blends.alioth.debian.org/

    6. http://debian-med.alioth.debian.org

    7. http://wiki.debian.org/DebianScience/Blend

Linking Applications with Data

  • Mentor: SteffenMoeller

  • Summary: Further develop / integrate efforts to manage public data with Debian

  • Required skills:

    • Perl + good general programming
    • English
  • Description: Many applications in scientific environments ship publicly available data with its source code. This may be

    • directly related to its the application's core functionality (e.g. description of restriction enzymes' sequence specificity),
    • part of the documentation (example)
    Fairly often such data is provided by a third party or expects the user to perfom the download. And other tools may provide/expect the same. It would then be saving resources and increase efficiency to
    • have installation should be performed only once
    • know updates to be supported and triggerable e.g. by cron

    Many larger databases have a considerable number of tools associated with it. The tool needs to be aware of those dependencies and perform respective post-processing with every such update. The Debian Med community has developed getData [1] for this purpose. Recently, the tool BioMaj was added to the distribution. The student shall investigate a series of scenarios in which the ?UniProt [2] database is used and perform respective downstream work with EMBOSS and NCBI BLAST by some automatism. Further thinking shall involve

    • how to install several versions in parallel
    • how to prepare Debian packages for individual database that may function as build/runtime dependencies
    Whatever means is developed, it shall be as close to how Debian works as possible.

    [1] http://wiki.debian.org/getData [2] http://www.uniprot.org

Measuring Team Performance