DOCSLIB.ORG

Deliverable 4: Analysis of Software Development Methodologies Used in the FOSS Communities

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Deliverable 4: Analysis of Software Development Methodologies Used in the FOSS Communities WP1 DIGIT B1 - EP Pilot Project 645 Deliverable 4: Analysis of Software Development Methodologies Used in the FOSS Communities Specific contract n°226 under Framework Contract n° DI/07172 – ABCIII February 2016 DIGIT Fossa WP1 – Governance and Quality of Software Code – Auditing of Free and Open Source Software. Deliverable 4: Analysis of Software Development Methodologies Used in the FOSS Communities Author: Disclaimer The information and views set out in this publication are those of the author(s) and do not necessarily reflect the official opinion of the Commission. The content, conclusions and recommendations set out in this publication are elaborated in the specific context of the EU – FOSSA project. The Commission does not guarantee the accuracy of the data included in this study. All representations, warranties, undertakings and guarantees relating to the report are excluded, particularly concerning – but not limited to – the qualities of the assessed projects and products. Neither the Commission nor any person acting on the Commission’s behalf may be held responsible for the use that may be made of the information contained herein. © European Union, 2016. Reuse is authorised, without prejudice to the rights of the Commission and of the author(s), provided that the source of the publication is acknowledged. The reuse policy of the European Commission is implemented by a Decision of 12 December 2011. Document elaborated in the specific context of the EU – FOSSA project. Reuse or reproduction authorised without prejudice to the Commission’s or the authors’ rights. Page 2 of 146 DIGIT Fossa WP1 – Governance and Quality of Software Code – Auditing of Free and Open Source Software. Deliverable 4: Analysis of Software Development Methodologies Used in the FOSS Communities Contents CONTENTS............................................................................................................................................. 3 LIST OF TABLES ................................................................................................................................... 6 LIST OF FIGURES ................................................................................................................................. 7 ACRONYMS AND ABBREVIATIONS ................................................................................................... 8 1 INTRODUCTION .............................................................................................................................. 9 1.1. OBJECTIVE OF THIS DOCUMENT AND INTENDED AUDIENCE ............................................................. 9 1.2. SCOPE ........................................................................................................................................ 9 1.3. DOCUMENT STRUCTURE .............................................................................................................. 9 1.4. KEY SUCCESS FACTORS ............................................................................................................ 10 1.5. DELIVERABLES .......................................................................................................................... 10 2 METHODOLOGICAL APPROACH TO BUILDING THE ANALYSIS ........................................... 11 2.1. SELECTION OF PROJECTS, ENGAGEMENT WITH FREE AND OPEN SOURCE SOFTWARE COMMUNITIES AND INFORMATION GATHERING ............................................................................................................. 11 2.2. INFORMATION CLASSIFICATION AND FILTERING PROCESS ............................................................ 12 2.3. ANALYSIS OF THE INFORMATION ................................................................................................. 12 3 SOFTWARE DEVELOPMENT METHODOLOGIES, BEST PRACTICES, FRAMEWORKS, LIBRARIES AND TOOLS USED IN THE PROJECTS ANALYSED FROM THE FOSS COMMUNITIES ..................................................................................................................................... 14 3.1. METHODOLOGIES USED BY THE ANALYSED FOSS COMMUNITIES DURING THE SOFTWARE DEVELOPMENT LIFECYCLE .................................................................................................................... 15 3.2. BEST PRACTICES USED BY THE ANALYSED FOSS COMMUNITIES DURING THE SOFTWARE DEVELOPMENT LIFECYCLE .................................................................................................................... 19 3.3. TOOLS USED BY THE ANALYSED FOSS COMMUNITIES DURING THE SOFTWARE DEVELOPMENT LIFECYCLE ........................................................................................................................................... 74 3.4. LIBRARIES AND BUILDING BLOCKS USED BY THE ANALYSED FOSS COMMUNITIES DURING THE SOFTWARE DEVELOPMENT LIFECYCLE ................................................................................................ 110 3.5. PROGRAMMING LANGUAGES USED BY THE ANALYSED FOSS COMMUNITIES DURING THE SOFTWARE DEVELOPMENT LIFECYCLE .................................................................................................................. 116 4 ANALYSIS OF IDENTIFIED SOFTWARE DEVELOPMENT METHODOLOGIES USED IN FOSS COMMUNITIES ................................................................................................................................... 122 4.1. PROJECT MANAGEMENT .......................................................................................................... 123 Document elaborated in the specific context of the EU – FOSSA project. Reuse or reproduction authorised without prejudice to the Commission’s or the authors’ rights. Page 3 of 146 DIGIT Fossa WP1 – Governance and Quality of Software Code – Auditing of Free and Open Source Software. Deliverable 4: Analysis of Software Development Methodologies Used in the FOSS Communities 4.1.1. Methodologies ................................................................................................................ 123 4.1.2. Conclusion ...................................................................................................................... 125 4.2. SOFTWARE DEVELOPMENT LIFECYCLE ..................................................................................... 125 4.2.1. Software Development Lifecycle Methodologies ........................................................... 125 4.2.1.1. Methodologies ............................................................................................................. 125 4.2.1.2. Tools ........................................................................................................................... 126 4.2.1.3. Conclusion .................................................................................................................. 127 4.2.2. Security Definition ........................................................................................................... 127 4.2.2.1. Security Requirements ................................................................................................ 127 4.2.2.2. Security Awareness .................................................................................................... 128 4.2.2.3. Conclusion .................................................................................................................. 130 4.2.3. Testing and Validation .................................................................................................... 130 4.2.3.1. Automatic Testing ....................................................................................................... 131 4.2.3.2. Security Testing .......................................................................................................... 131 4.2.3.3. Validation Testing ........................................................................................................ 132 4.2.3.4. Tools and Methods...................................................................................................... 132 4.2.4. Release Management .................................................................................................... 132 4.2.4.1. Conclusion .................................................................................................................. 133 4.2.4.2. Release Planning ........................................................................................................ 133 4.2.4.3. Continuous Testing and Validation ............................................................................. 133 4.2.4.4. Channels and Tools Used ........................................................................................... 134 4.2.4.5. Conclusion .................................................................................................................. 134 4.2.5. Inspection and Code Review .......................................................................................... 135 4.2.5.1. Code Review ............................................................................................................... 135 4.2.5.2. Tools ........................................................................................................................... 135 4.2.5.3. Projects Reviewed by Security Experts ...................................................................... 136 4.2.5.4. Phase Where the Project is Reviewed by Security Experts ....................................... 136 4.2.5.5. Conclusion .................................................................................................................
Load more

Recommended publications
  • Creating Awareness for the Use of Opensource Systems in the Public Sector in Afghanistan
    A Service of Leibniz-Informationszentrum econstor Wirtschaft Leibniz Information Centre Make Your Publications Visible. zbw for Economics Hussini, Sayed Jahed (Ed.); Finke, Wolfgang F. (Ed.) Research Report Creating Awareness for the Use of OpenSource Systems in the Public Sector in Afghanistan. Workshop Proceedings, Sept. 15-17, 2012, Kabul/ Afghanistan Wirtschaftswissenschaftliche Schriften, No. 02/2013 Provided in Cooperation with: Ernst-Abbe-Hochschule Jena – University of Applied Sciences, Department of Business Administration Suggested Citation: Hussini, Sayed Jahed (Ed.); Finke, Wolfgang F. (Ed.) (2013) : Creating Awareness for the Use of OpenSource Systems in the Public Sector in Afghanistan. Workshop Proceedings, Sept. 15-17, 2012, Kabul/Afghanistan, Wirtschaftswissenschaftliche Schriften, No. 02/2013, ISBN 3-939046-32-9, Ernst-Abbe-Fachhochschule, Fachbereich Betriebswirtschaft, Jena, http://nbn-resolving.de/urn:nbn:de:gbv:27-20130408-110626-4 This Version is available at: http://hdl.handle.net/10419/71197 Standard-Nutzungsbedingungen: Terms of use: Die Dokumente auf EconStor dürfen zu eigenen wissenschaftlichen Documents in EconStor may be saved and copied for your Zwecken und zum Privatgebrauch gespeichert und kopiert werden. personal and scholarly purposes. Sie dürfen die Dokumente nicht für öffentliche oder kommerzielle You are not to copy documents for public or commercial Zwecke vervielfältigen, öffentlich ausstellen, öffentlich zugänglich purposes, to exhibit the documents publicly, to make them machen, vertreiben oder anderweitig nutzen. publicly available on the internet, or to distribute or otherwise use the documents in public. Sofern die Verfasser die Dokumente unter Open-Content-Lizenzen (insbesondere CC-Lizenzen) zur Verfügung gestellt haben sollten, If the documents have been made available under an Open gelten abweichend von diesen Nutzungsbedingungen die in der dort Content Licence (especially Creative Commons Licences), you genannten Lizenz gewährten Nutzungsrechte.
    [Show full text]
  • LPC-Link2 Debug Probe Firmware Programming Rev
    LPC-Link2 Debug Probe Firmware Programming Rev. 2.1.0 — 22 January, 2020 User Guide NXP Semiconductors LPC-Link2 Debug Probe Firmware Programming 22 January, 2020 Copyright © 2015-2018 NXP Semiconductors All rights reserved. LPC-Link2 Debug Probe Firmware Programming - All information provided in this document is subject to legal disclaimers © 2015-2018 NXP Semiconductors. All rights reserved. User Guide Rev. 2.1.0 — 22 January, 2020 ii NXP Semiconductors LPC-Link2 Debug Probe Firmware Programming 1. Revision History .................................................................................................. 1 1.1. 2.1.1 ........................................................................................................ 1 1.2. v2.0.0 ....................................................................................................... 1 1.3. v1.8.2 ....................................................................................................... 1 1.4. v1.5.2 ....................................................................................................... 1 1.5. v1.5 ......................................................................................................... 1 2. Introduction ......................................................................................................... 2 3. Quick Start .......................................................................................................... 3 4. Debug Firmware Variants and Drivers .................................................................
    [Show full text]
  • Management of Programmable Safety Systems
    MANAGEMENT OF PROGRAMMABLE SAFETY SYSTEMS erhtjhtyhy JOE LENNER Argonne National Laboratory Advanced Photon Source Safety Interlocks Group 9/11/2019 MANAGEMENT OF PROGRAMMABLE SAFETY SYSTEMS Applicable Standards . IEC 61508 is the parent standard – Applicable in any situation – Used when no applicable child IEC 61800-5-2 standard exists Elec Drives – Very general, many requirements are EN 50128 Railway overly complex ISO 13849 . Child Standards Machinery IEC – Specialize the requirements of IEC 60601 61508 61508 for a specific application Medical Dev IEC 62061 – If you meet the requirements of the Machinery child, you meet the relevant IEC 61511 IEC Process Ind. 50156 requirements of 61508 Furnaces . Best fit for Accelerators – IEC 62061 – ISO 13849 – IEC 61511 2 MANAGEMENT OF PROGRAMMABLE SAFETY SYSTEMS Certified hardware benefits . Use of a single PLC – Eliminates redundant systems and associated wiring. – Ability to clearly separate safety from non-safety tasks – Built-in diagnostics – Safety I/O allows reduction of relays . Programming – Use of certified and proven functions reduces programming effort • Easier to apply = Less errors – Reduces safety and standard programs/tasks • Reduced size of safety program • Reduces review & test time 3 MANAGEMENT OF PROGRAMMABLE SAFETY SYSTEMS Vendor Software Management . Programming tool updates – Only when necessary • The “Microsoft“ effect • Development platform support . Firmware Updates – Quarterly reviews unless alert 4 MANAGEMENT OF PROGRAMMABLE SAFETY SYSTEMS Software . The latest generation
    [Show full text]
  • Vulnerability Scanners and Penetration Testing
    Vulnerability Scanners and Penetration Testing Introduction OBJECTIVE: CompTIA Security+ Domain: Domain 3: Threats and Vulnerabilities CompTIA Security+ Objective Mapping: Objective 3.8: Explain the proper use of penetration testing versus vulnerability scanning. OVERVIEW: In this lab, you will scan a host to discover security holes. Discovering vulnerabilities is critical so they can be patched before attackers compromise your system. Key Term Description OpenVAS an open source vulnerability scanner gaining a higher level of access (possible administrative access) from account with less Privilege escalation permissions and rights Zenmap a GUI front end for nmap, will allow you to scan for open ports and services Metasploit a framework that contains exploits for various information systems nmap a port scanner which will indicate whether ports are open or closed on a remote system Nmap and OpenVAS 1. Click on the External Kali 2 Linux icon on the topology. Type root for the username, and click the Next button. TOPOLOGY MACHINES If the Kali Linux is displaying the time, and not the logon box, press the Enter Key. EXTERNAL KALI 2 USERNAME 2. For the password, type toor (root spelled backwards), and click the Sign In button. EXTERNAL KALI 2 PASSWORD 3. Click the terminal icon (second from the top) to launch the Linux terminal. OPENING THE KALI 2 TERMINAL 4. Type the following command to scan the firewall for open ports, then press Enter. root@kali2:~# nmap 203.0.113.100 NMAP 5. Type the following command, then press Enter to open Zenmap. After Zenmap opens, type 203.0.113.100 in the Target box and then click the Scan button to launch an intense scan.
    [Show full text]
  • Optimization of Software Quality Using Management and Technical Review Techniques
    International Journal of Computer Trends and Technology (IJCTT) – volume 17 Number 6 Nov 2014 Optimization of Software Quality using Management and Technical Review Techniques Inibehe Emmanuel Akpannah Post Graduate Student (MSc. Information Technology), SRM University, Chennai, India Abstract compromising the security of the entire system. Optimizing the quality of software is a function of Improving the quality of our software process leads the degree of reviews made during the early life of to minimal rework, cost effectiveness and also a software development process. Reviews detect meeting up with schedules, which all lead to errors and potential errors early in the software improvement in capability measurement. Software development process. The errors detected during review is a chain process, it is dynamic and review the early life cycle of software are least expensive needs to be performed at every phase of the to correct. Efficient involvement in software development process until there is a transition to the inspections and technical reviews, help developers testing phase. improve their own skills, thereby mitigating the Software design and code review is a phase in the occurrence of errors in the later stage of software software development process in which development process. The ideas gathered on this programmers (authors of codes), quality assurance paper point that a properly implemented program of (QA) team, and peer reviewers get together to technical and management reviews drastically review design and code [9]. One way of optimizing reduces the time as well as the cost required for the quality of software is finding and correcting testing, debugging, and reworking, and dramatically errors at the early stage of a software development improves the quality of the resulting product.
    [Show full text]
  • List of NMAP Scripts Use with the Nmap –Script Option
    List of NMAP Scripts Use with the nmap –script option Retrieves information from a listening acarsd daemon. Acarsd decodes ACARS (Aircraft Communication Addressing and Reporting System) data in real time. The information retrieved acarsd-info by this script includes the daemon version, API version, administrator e-mail address and listening frequency. Shows extra information about IPv6 addresses, such as address-info embedded MAC or IPv4 addresses when available. Performs password guessing against Apple Filing Protocol afp-brute (AFP). Attempts to get useful information about files from AFP afp-ls volumes. The output is intended to resemble the output of ls. Detects the Mac OS X AFP directory traversal vulnerability, afp-path-vuln CVE-2010-0533. Shows AFP server information. This information includes the server's hostname, IPv4 and IPv6 addresses, and hardware type afp-serverinfo (for example Macmini or MacBookPro). Shows AFP shares and ACLs. afp-showmount Retrieves the authentication scheme and realm of an AJP service ajp-auth (Apache JServ Protocol) that requires authentication. Performs brute force passwords auditing against the Apache JServ protocol. The Apache JServ Protocol is commonly used by ajp-brute web servers to communicate with back-end Java application server containers. Performs a HEAD or GET request against either the root directory or any optional directory of an Apache JServ Protocol ajp-headers server and returns the server response headers. Discovers which options are supported by the AJP (Apache JServ Protocol) server by sending an OPTIONS request and lists ajp-methods potentially risky methods. ajp-request Requests a URI over the Apache JServ Protocol and displays the result (or stores it in a file).
    [Show full text]
  • Visual Programming: a Programming Tool for Increasing Mathematics Achivement
    ARTICLES VISUAL PROGRAMMING: A PROGRAMMING TOOL FOR INCREASING MATHEMATICS ACHIVEMENT By CHERYL SWANIER * CHERYL D. SEALS ** ELODIE BILLIONNIERE *** * Associate Professor, Mathematics and Computer Science Department, Fort Valley State University ** Associate Professor, Computer Science and Software Engineering Department, Auburn University *** Doctoral Student, Computer Science and Engineering Department, Arizona State University ABSTRACT This paper aims to address the need of increasing student achievement in mathematics using a visual programming language such as Scratch. This visual programming language facilitates creating an environment where students in K-12 education can develop mathematical simulations while learning a visual programming language at the same time. Furthermore, the study of visual programming tools as a means to increase student achievement in mathematics could possibly generate interests within the computer-supported collaborative learning community. According to Jerome Bruner in Children Learn By Doing, "knowing how something is put together is worth a thousand facts about it. It permits you to go beyond it” (Bruner, 1984, p.183). Keywords : Achievement, Creativity, End User Programming, Mathematics Education, K-12, Learning, Scratch, Squeak, Visual Programming INTRODUCTION programming language as a tool to create Across the nation, math scores lag (Lewin, 2006). Students mathematical tutorials. Additionally, this paper provides a are performing lower than ever. Lewin reports, for “the modicum of information as it relates to the educational second time in a generation, education officials are value of visual programming to mathematical rethinking the teaching of math in American schools” achievement. Peppler and Kafai (2007) indicate “game (p.1). It is imperative that higher education, industry, and players program their own games and learn about K-12 collaborate to ascertain a viable solution to the software and interface design.
    [Show full text]
  • Software Reviews
    Software Reviews Software Engineering II WS 2020/21 Enterprise Platform and Integration Concepts Image by Chris Isherwood from flickr: https://www.flickr.com/photos/isherwoodchris/6807654905/ (CC BY-SA 2.0) Review Meetings a software product is [examined by] project personnel, “ managers, users, customers, user representatives, or other interested parties for comment or approval —IEEE1028 ” Principles ■ Generate comments on software ■ Several sets of eyes check ■ Emphasis on people over tools Code Reviews — Software Engineering II 2 Software Reviews Motivation ■ Improve code ■ Discuss alternative solutions ■ Transfer knowledge ■ Find defects Code Reviews — Software Engineering II Image by Glen Lipka: http://commadot.com/wtf-per-minute/ 3 Involved Roles Manager ■ Assessment is an important task for manager ■ Possible lack of deep technical understanding ■ Assessment of product vs. assessment of person ■ Outsider in review process ■ Support with resources (time, staff, rooms, …) Developer ■ Should not justify but only explain their results ■ No boss should take part at review Code Reviews — Software Engineering II 4 Review Team Team lead ■ Responsible for quality of review & moderation ■ Technical, personal and administrative competence Reviewer ■ Study the material before first meeting ■ Don’t try to achieve personal targets! ■ Give positive and negative comments on review artifacts Recorder ■ Any reviewer, can rotate even in review meeting ■ Protocol as basis for final review document Code Reviews — Software Engineering II 5 Tasks of
    [Show full text]
  • Reflections on Applying the Growth Mindset Approach to Computer Programming Courses
    2018 Proceedings of the EDSIG Conference ISSN: 2473-3857 Norfolk, Virginia USA v4 n4641 Reflections on Applying the Growth Mindset Approach to Computer Programming Courses Katherine Carl Payne [email protected] Jeffry Babb [email protected] Amjad Abdullat [email protected] Department of Computer Information and Decision Management West Texas A&M University Canyon, Texas 79016, USA Abstract This paper provides motivation for the exploration of the adoption of Growth Mindset techniques in computer programming courses. This motivation is provided via an ethnographic account of the implementation of Growth Mindset concepts in the design and delivery of two consecutive computer programming courses. We present components of a Growth Mindset approach to STEM education and illustrate how they can be implemented in computing courses. Experiences of an instructor in two consecutive computer programming courses at a private regional undergraduate university in the southwestern United States are described and analyzed. Six students enrolled in the required Java course in the fall semester opted to take the elective Python course in the spring semester. Keywords: Growth mindset, reflective teaching practice, computer programming, STEM education, pedagogy 1. INTRODUCTION The work of Carol Dweck on what is termed the “Growth Mindset” has received significant As educators in STEM courses, we frequently hear attention in primary and secondary math students utter the phrase “I’m not a technical education and has recently experienced a person” or “I’m not good with computers.” I renaissance through application to math higher receive messages from concerned students education (Silva & White, 2013). Her work and expressing this sentiment every semester.
    [Show full text]
  • Openvas Reporting Documentation Release 1.4.4
    OpenVAS Reporting Documentation Release 1.4.4 TheGroundZero May 23, 2021 Contents 1 Table of contents 3 1.1 Changelog..............................................3 1.2 Usage.................................................3 1.2.1 Installation.........................................3 1.2.2 Command line usage....................................4 2 What’s OpenVAS Reporting?9 3 Why create this tool? 11 4 Aren’t there other tools to achieve this? 13 5 How can I help? 15 6 TODO list 17 i ii OpenVAS Reporting Documentation, Release 1.4.4 A tool to convert OpenVAS XML into reports. Contents 1 OpenVAS Reporting Documentation, Release 1.4.4 2 Contents CHAPTER 1 Table of contents 1.1 Changelog 1.4.2 - Fixed "ValueError: Unknown format code ’f’ for object of type ’str’" 1.4.1 - Small bugfixes and code refactoring 1.4.0 - Use Word template for report building 1.3.1 - Add charts to Word document using matplotlib. Some code clean-up and small lay-out changes in Excel. 1.3.0 - Fix retrieval of description and other useful info by parsing <tags> instead of <description> 1.2.3 - Implement https://github.com/cr0hn/openvas_to_report/pull/12 1.2.2 - Fix bug where port info was not correctly extracted 1.2.1 - Fix bug where affected hosts were added on wrong row in Excel export 1.2.0 - Functional export to Word document (.docx). Includes some formatting. TODO: graphs 1.1.0a - Support for exporting to Word document (.docx). Limited formatting, needs more testing 1.0.1a - Small updates, preparing for export to other formats 1.0.0 - First official release, supports export to Excel with graphs, ToC and worksheet per vulnerability 1.2 Usage 1.2.1 Installation You can install this package directly from source by cloning the Git repository.
    [Show full text]
  • SPI Annual Report 2015
    Software in the Public Interest, Inc. 2015 Annual Report July 12, 2016 To the membership, board and friends of Software in the Public Interest, Inc: As mandated by Article 8 of the SPI Bylaws, I respectfully submit this annual report on the activities of Software in the Public Interest, Inc. and extend my thanks to all of those who contributed to the mission of SPI in the past year. { Martin Michlmayr, SPI Secretary 1 Contents 1 President's Welcome3 2 Committee Reports4 2.1 Membership Committee.......................4 2.1.1 Statistics...........................4 3 Board Report5 3.1 Board Members............................5 3.2 Board Changes............................6 3.3 Elections................................6 4 Treasurer's Report7 4.1 Income Statement..........................7 4.2 Balance Sheet............................. 13 5 Member Project Reports 16 5.1 New Associated Projects....................... 16 5.2 Updates from Associated Projects................. 16 5.2.1 0 A.D.............................. 16 5.2.2 Chakra............................ 16 5.2.3 Debian............................. 17 5.2.4 Drizzle............................. 17 5.2.5 FFmpeg............................ 18 5.2.6 GNU TeXmacs........................ 18 5.2.7 Jenkins............................ 18 5.2.8 LibreOffice.......................... 18 5.2.9 OFTC............................. 19 5.2.10 PostgreSQL.......................... 19 5.2.11 Privoxy............................ 19 5.2.12 The Mana World....................... 19 A About SPI 21 2 Chapter 1 President's Welcome SPI continues to focus on our core services, quietly and competently supporting the activities of our associated projects. A huge thank-you to everyone, particularly our board and other key volun- teers, whose various contributions of time and attention over the last year made continued SPI operations possible! { Bdale Garbee, SPI President 3 Chapter 2 Committee Reports 2.1 Membership Committee 2.1.1 Statistics On January 1, 2015 we had 512 contributing and 501 non-contributing mem- bers.
    [Show full text]
  • Pipenightdreams Osgcal-Doc Mumudvb Mpg123-Alsa Tbb
    pipenightdreams osgcal-doc mumudvb mpg123-alsa tbb-examples libgammu4-dbg gcc-4.1-doc snort-rules-default davical cutmp3 libevolution5.0-cil aspell-am python-gobject-doc openoffice.org-l10n-mn libc6-xen xserver-xorg trophy-data t38modem pioneers-console libnb-platform10-java libgtkglext1-ruby libboost-wave1.39-dev drgenius bfbtester libchromexvmcpro1 isdnutils-xtools ubuntuone-client openoffice.org2-math openoffice.org-l10n-lt lsb-cxx-ia32 kdeartwork-emoticons-kde4 wmpuzzle trafshow python-plplot lx-gdb link-monitor-applet libscm-dev liblog-agent-logger-perl libccrtp-doc libclass-throwable-perl kde-i18n-csb jack-jconv hamradio-menus coinor-libvol-doc msx-emulator bitbake nabi language-pack-gnome-zh libpaperg popularity-contest xracer-tools xfont-nexus opendrim-lmp-baseserver libvorbisfile-ruby liblinebreak-doc libgfcui-2.0-0c2a-dbg libblacs-mpi-dev dict-freedict-spa-eng blender-ogrexml aspell-da x11-apps openoffice.org-l10n-lv openoffice.org-l10n-nl pnmtopng libodbcinstq1 libhsqldb-java-doc libmono-addins-gui0.2-cil sg3-utils linux-backports-modules-alsa-2.6.31-19-generic yorick-yeti-gsl python-pymssql plasma-widget-cpuload mcpp gpsim-lcd cl-csv libhtml-clean-perl asterisk-dbg apt-dater-dbg libgnome-mag1-dev language-pack-gnome-yo python-crypto svn-autoreleasedeb sugar-terminal-activity mii-diag maria-doc libplexus-component-api-java-doc libhugs-hgl-bundled libchipcard-libgwenhywfar47-plugins libghc6-random-dev freefem3d ezmlm cakephp-scripts aspell-ar ara-byte not+sparc openoffice.org-l10n-nn linux-backports-modules-karmic-generic-pae
    [Show full text]