KERN Party the 3Rd Packages

Total Page:16

File Type:pdf, Size:1020Kb

KERN Party the 3Rd Packages KERN Gijs Molenaara,b, Oleg Smirnovb,a aSKA Sounth Africa, 3rd Floor, The Park, Park Road, Pinelands, 7405, South Africa bDepartment of Physics & Electronics, Rhodes University, PO Box 94, Grahamstown, 6140, South Africa Abstract KERN is a bi-annually released set of radio astronomical software packages. It should contain most of the standard tools that a radio astronomer needs to work with radio telescope data. The goal of KERN is to save time and prevent frustration in setting up of scientific pipelines, and to assist in achieving scientific reproducibility. Keywords: software, packaging, radio astronomy, reproducible science, containerisation 1. Introduction intended to be used for radio astronomical data re- duction. The installation of scientific software for use in astron- omy can be notoriously challenging. The radio astronomy The name KERN means ‘core’ in Dutch and Afrikaans. community has a limited number of dedicated software en- gineers and often lacks the human resources to dedicate to 2. The target platform industrial-quality software development and maintenance. It is not uncommon that poorly written and badly main- A quick look around various astronomy institutes and tained software packages of high complexity are used by universities shows that GNU/Linux and OS X are the most scientists around the world, as these provide some set of used personal computing platforms. On the server side algorithmic features not available elsewhere. it is without question GNU/Linux. Compared to OS X, KERN has been created to facilitate scientists and sys- GNU/Linux is an open source and a freely available plat- tem administrators. KERN is the name of the project to form, which is also a clear advantage. These facts com- structure and automate the packaging of scientific soft- bined result in the choice for Linux as the KERN platform. ware. The main deliverable is the KERN suite, a bi- However, further consideration was required before se- annually released set of 3rd party open source scientific lection of the most suitable platform. There are various software packages. flavours of GNU/Linux, with different design philosophies The primary goals of KERN are: to make it easier to in- and varying packaging formats. The most popular dis- stall the scientific software, to supply a consistent working tributions can be split into two groups, RPM (Red Hat environment to a scientist and to improve interoperability Package Manager) package and Debian package based dis- and interchangeability. tributions. There is no major advantage or disadvantage Due to human resource limitations, we target KERN to either package format. Although there are diverse local to one operating system and distribution. This is unfor- trends, it is our experience that in the South African radio tunate, but recent development and adaptation of con- astronomy community, the majority of frequently utilised tainerisation technology make it easier to deploy packaged platforms are Debian based, specifically Ubuntu LTS. This software on most platforms. Limiting us to only one plat- distribution also appears to have popularity worldwide. arXiv:1710.09145v1 [astro-ph.IM] 25 Oct 2017 form enables us to focus on performing the packaging only Therefore, it was the most logical choice as KERNs target once, and to do this well. The choice of this one platform platform. is then based on install base (desktop, server) and ease of use for user and developer (package creator). The intended audience of this paper is threefold: 3. Other packaging methods • the user, who is interested in using the software bun- In this section we discuss other packaging systems avail- dled with KERN, able to us, and motivate our choice not to use these. • the developer, who wants his radio astronomy soft- 3.1. Anaconda ware available to a wider range of users and A packaging effort named Anaconda is currently gain- • the system administrator who is setting up systems ing popularity. Anaconda is a cross platform set of scien- tific software, with a focus on Python. It supports GNU/Linux, Preprint submitted to Astronomy and Computing, elsevier October 26, 2017 Windows and OS X. OS X is also often used as a desktop casacore depends on the casacore package and both pack- environment in radio astronomy. Supporting OS X would ages need to have a matching ABI. If the version of casacore be advantageous for many end users. differs between compile time and run time, the library does We have performed experiments with packaging pack- not work. Pip does not have any control over reinforcing ages for Anaconda. Users have reported that Anaconda the shared library version. This would imply that we need is easy to operate; however, at the time of writing, the to create, upload and maintain wheels for every casacore packaging procedure is cumbersome for the developer. In released. Moreover, with every casacore release we would effect, developers cannot generate the same high quality, also need to create a wheel for every OS and supported seamlessly installable packages, as is achievable with na- profile. The exponential growth of this cartesian product tive Linux packaging methods. Additionally, Anaconda quickly becomes cumbersome for the package maintainers. lacks an equivalent to Debians Lintian, a packaging tool These limitations combined with pip’s inability to han- that dissects a Debian package and tries to find bugs and dle non-Python libraries, make pip an ill suited candidate violations of the Debian policies. for our packaging effort. Nevertheless, this does not mean Various software packages in KERN are not created pip and KERN cannot be combined. with OS X support in mind thus requiring various modi- The approach we adopt is that we prepackage impure fications to the source code. Also, compilation procedures python libraries and bundle them with KERN. These Python can vary greatly across platforms, doubling the packaging packages are then precompiled against a set of specific li- and maintenance effort if we would support OS X as a brary versions. This guarantees the ABIs always match platform. up. Users can then augment the system python installa- In addition, Linux distributions come with a large set of tion, or a Python virtual environment, with packages from prepackaged software, which eliminates the need to pack- the packaging index using pip. age many dependencies. Using Anaconda would necessi- Although KERN supports both Python 2 and Python tate packaging up many dependencies ourselves. 3, most Python packages in KERN only support Python The limitations of Anaconda led to the preference of version 2. For now, the only package that supports Python Debian- over Anaconda packages. 3 is python-casacore. The KERN Python 3 package for casacore is named python3-casacore. 3.2. Python and pip The Python programming language has become the 3.3. Collaboration with Debian most widely used language in astronomy [2]. Python comes Ubuntu is directly based on Debian and thus is similar with a package manager called pip. Pip assists in down- to Debian. Nonetheless, due to version differences in the loading and installing Python packages from the Python bundled libraries in each distribution, KERN packages are package index (PyPi). Another useful tool for setting up unlikely to run on Debian. Fortunately the packaging pro- Python environments is called virtualenv. Virtualenv cedure is identical for Debian and Ubuntu, which makes enables a user to set up one or more isolated Python envi- creating true Debian packages a matter of a recompilation ronments without system administrator rights. The com- of the source package. bination of these two tools enables the end user to set up In contrast, the build system, dependency management various custom environments with specific versions of de- and library management for RPM is completely different. pendencies. For pure Python projects, pip and virtualenv Porting our packages to RPM is non-trivial, and main- are cross platform and independent of the host operating taining support for RPM based distributions would imply system package manager. However, pip is less suited for doubling the required effort. impure Python projects. Some Python libraries depend We have established a collaboration with Debian de- on non-Python run time libraries and/or non-Python de- velopers, and some packages from KERN (e.g. casacore velopment headers compile time, making them “impure”. and aoflagger) have been incorporated into Debian di- A recent improvement to the Python Packaging system is rectly. These packages have been uploaded to the Debian the introduction of wheels. Wheels are pre-compiled bi- archive, and changes are synchronised between KERN and nary Python packages. These do not require compilation the Debian archive. and will work if the packaged library does not have unusual Not all KERN packages are suitable for uploading to requirements. An example of a independent binary wheel Debian. Packages with a small user base or packages that is Numpy. Numpy only depends on Python and a small are fragile and receive continuous fixes (as opposed to for- set of system libraries. The Application Binary Interface mal release) are not well suited to this distribution model, (ABI) differs across host platforms and python versions, since it can take some time before a package ends up in a requiring a wheel for every platform and python combina- Debian release. For the more stable packages in KERN, tion. These are supplied on PyPi and the correct version we expect a continuation of this effort, with more packages is automatically selected by pip on installation. ending up in Debian in the future. Problems arise for example, with the python-casacore package, which has more unusual dependencies. Python- 2 4. Usage the casacore data package is not required if one is not cal- culating e.g. coordinate conversions, but in practice many To use the packages of KERN, one needs to add the components of casacore will fail or give warnings if the KERN remote repository to the system.
Recommended publications
  • Debian Developer's Reference Version 12.0, Released on 2021-09-01
    Debian Developer’s Reference Release 12.0 Developer’s Reference Team 2021-09-01 CONTENTS 1 Scope of This Document 3 2 Applying to Become a Member5 2.1 Getting started..............................................5 2.2 Debian mentors and sponsors......................................6 2.3 Registering as a Debian member.....................................6 3 Debian Developer's Duties 9 3.1 Package Maintainer's Duties.......................................9 3.1.1 Work towards the next stable release............................9 3.1.2 Maintain packages in stable .................................9 3.1.3 Manage release-critical bugs.................................. 10 3.1.4 Coordination with upstream developers............................ 10 3.2 Administrative Duties.......................................... 10 3.2.1 Maintaining your Debian information............................. 11 3.2.2 Maintaining your public key.................................. 11 3.2.3 Voting.............................................. 11 3.2.4 Going on vacation gracefully.................................. 12 3.2.5 Retiring............................................. 12 3.2.6 Returning after retirement................................... 13 4 Resources for Debian Members 15 4.1 Mailing lists............................................... 15 4.1.1 Basic rules for use....................................... 15 4.1.2 Core development mailing lists................................. 15 4.1.3 Special lists........................................... 16 4.1.4 Requesting new
    [Show full text]
  • Sbt-Native-Packager Release 1.0A1
    sbt-native-packager Release 1.0a1 Josh Suereth Sep 18, 2021 Contents 1 Introduction 1 1.1 Goals...................................................1 1.2 Scope...................................................1 1.3 Core Concepts..............................................2 2 Getting Started 5 2.1 Setup...................................................5 2.2 Your first package............................................5 3 Packaging Formats 7 3.1 Universal Plugin.............................................8 3.2 Linux Plugin............................................... 15 3.3 Debian Plugin.............................................. 21 3.4 Rpm Plugin................................................ 25 3.5 Docker Plugin.............................................. 31 3.6 Windows Plugin............................................. 38 3.7 JDKPackager Plugin........................................... 41 3.8 GraalVM Native Image Plugin...................................... 44 4 Project Archetypes 47 4.1 Java Application Archetype....................................... 47 4.2 Java Server Application Archetype................................... 54 4.3 Systemloaders.............................................. 59 4.4 Configuration Archetypes........................................ 62 4.5 Jlink Plugin................................................ 62 4.6 Archetype Cheatsheet.......................................... 64 5 Recipes 69 5.1 Custom Package Formats........................................ 69 5.2 Dealing with long classpaths......................................
    [Show full text]
  • Debian Packaging Tutorial
    Debian Packaging Tutorial Lucas Nussbaum [email protected] version 0.27 – 2021-01-08 Debian Packaging Tutorial 1 / 89 About this tutorial I Goal: tell you what you really need to know about Debian packaging I Modify existing packages I Create your own packages I Interact with the Debian community I Become a Debian power-user I Covers the most important points, but is not complete I You will need to read more documentation I Most of the content also applies to Debian derivative distributions I That includes Ubuntu Debian Packaging Tutorial 2 / 89 Outline 1 Introduction 2 Creating source packages 3 Building and testing packages 4 Practical session 1: modifying the grep package 5 Advanced packaging topics 6 Maintaining packages in Debian 7 Conclusions 8 Additional practical sessions 9 Answers to practical sessions Debian Packaging Tutorial 3 / 89 Outline 1 Introduction 2 Creating source packages 3 Building and testing packages 4 Practical session 1: modifying the grep package 5 Advanced packaging topics 6 Maintaining packages in Debian 7 Conclusions 8 Additional practical sessions 9 Answers to practical sessions Debian Packaging Tutorial 4 / 89 Debian I GNU/Linux distribution I 1st major distro developed “openly in the spirit of GNU” I Non-commercial, built collaboratively by over 1,000 volunteers I 3 main features: I Quality – culture of technical excellence We release when it’s ready I Freedom – devs and users bound by the Social Contract Promoting the culture of Free Software since 1993 I Independence – no (single)
    [Show full text]
  • I Deb, You Deb, Everybody Debs: Debian Packaging For
    I deb, you deb, everybody debs Debian packaging for beginners and experts alike Ondřej Surý • [email protected][email protected] • 25.­ 10. 2017 Contents ● .deb binary package structure ● Source package structure ● Basic toolchain ● Recommended toolchain ● Keeping the sources in git ● Clean build environment ● Misc... ● So how do I become Debian Developer? My Debian portfolio (since 2000) ● Mostly team maintained ● BIRD ● PHP + PECL (pkg-php) ● Cyrus SASL ○ Co-installable packages since 7.x ● Cyrus IMAPD ○ Longest serving PHP maintainer in Debian ● Apache2 + mod_md (fresh) (and still not crazy) ● ...other little stuff ● libjpeg-turbo ○ Transitioned Debian from IIJ JPEG (that Older work crazy guy) to libjpeg-turbo ● DNS Packaging Group ● GTK/GNOME/Freedesktop ○ CZ.NIC’s Knot DNS and Knot Resolver ● Redmine/Ruby ○ NLnet Lab’s NSD, Unbound, getdns, ldns Never again, it’s a straight road to madness ○ PowerDNS ○ ○ BIND 9 ● Berkeley DB and LMDB (pkg-db) ○ One Berkeley DB per release (yay!) Binary package structure ● ar archive consisting of: $ ar xv knot_2.0.1-4_amd64.deb x – debian-binary ○ debian-binary x – control.tar.gz x – data.tar.xz ■ .deb format version (2.0) ○ control.tar.gz $ dpkg-deb -X knot_2.0.1-4_amd64.deb output/ ./ ■ Package informatio (control) ./etc/ ■ Maintainer scripts […] ./usr/sbin/knotd ● {pre,post}{inst,rm} […] Misc (md5sum, conffiles) ■ $ dpkg-deb -e knot_2.0.1-4_amd64.deb DEBIAN/ ○ data.tar.xz $ ls DEBIAN/ conffiles control md5sums postinst postrm preinst ■ Actual content of the package prerm ■ This is what gets installed $ dpkg -I knot_2.0.1-4_amd64.deb ● Nástroje pro práci s .deb soubory new debian package, version 2.0.
    [Show full text]
  • Package Management Michael Tsai 2016/4/27 Pxeboot
    Package Management Michael Tsai 2016/4/27 PXEBoot • Diskless host operation • Boot ROM on your network interface card uses DHCP to get the initial network setting • Including the location of the boot file at a TFTP server • Then the boot file is used to initiate the operating system • The root file system can be mounted from a server (for example, using NFS) Setup your own PXE environment • http://goo.gl/Fgr0JT <— Ubuntu 16.04 LTS 64 bit server ISO • http://goo.gl/duqdjS <— Guide to setup a PXEBoot environment Software Installation • System administrators often perform the following: • Automating mass installations of OS’s (not covered today. Additional: • Maintaining custom OS configurations for the local environment • Keeping systems and applications patched and up to date • Managing add-on software packages Packages - WHY? • The old ways - .tar.gz (“zipped tar ball”) • Advantages of the use of packages: • Ability to roll back to the original state • Quick (binary packages v.s. compile from source) • Handles dependency • Ability to run scripts during installation Automation is important • Install software for once is easy • Install the same software for 10 times is boring and painful • Human errors (typo, you forgot to install one of them) • Human intervention takes the most time. • Use a tool to automate the process! The Old Ways • tar - “store and extract files from a tape or disk archive” • Example: tar zcvf nasa117.tar.gz nasa117/ (create a tar archive with all files in nasa117/) tar zxvf nasa117.tar.gz (extract nasa117.tar) • Commonly
    [Show full text]
  • Latest Version of Deb-Pkg-Tools Is Available on Pypi and Github
    deb-pkg-tools Release 8.4 Mar 09, 2021 Contents 1 User documentation 3 1.1 deb-pkg-tools: Debian packaging tools.................................3 2 API documentation 9 2.1 API documentation............................................9 3 Change log 53 3.1 Changelog................................................ 53 Python Module Index 81 Index 83 i ii deb-pkg-tools, Release 8.4 Welcome to the documentation of deb-pkg-tools version 8.4! The following sections are available: • User documentation • API documentation • Change log Contents 1 deb-pkg-tools, Release 8.4 2 Contents CHAPTER 1 User documentation The readme is the best place to start reading, it’s targeted at all users and documents the command line interface: 1.1 deb-pkg-tools: Debian packaging tools The Python package deb-pkg-tools is a collection of functions to build and inspect Debian binary packages and repos- itories of binary packages. Its primary use case is to automate builds. Some of the functionality is exposed in the command line interface (documented below) because it’s very convenient to use in shell scripts, while other functionality is meant to be used as a Python API. The package is currently tested on cPython 2.7, 3.5+ and PyPy (2.7). Please note that deb-pkg-tools is quite opinionated about how Debian binary packages should be built and it enforces some of these opinions on its users. Most of this can be avoided with optional function arguments and/or environment variables. If you find something that doesn’t work to your liking and you can’t work around it, feel free to ask for an additional configuration option; I try to keep an open mind about the possible use cases of my projects.
    [Show full text]
  • Debian Policy Manual Release 4.6.0.1
    Debian Policy Manual Release 4.6.0.1 The Debian Policy Mailing List Aug 18, 2021 CONTENTS 1 About this manual 3 1.1 Scope ................................................... 3 1.2 New versions of this document ...................................... 4 1.3 Authors and Maintainers ......................................... 4 1.3.1 Early history ........................................... 4 1.3.2 Current process ......................................... 4 1.3.3 Improvements .......................................... 5 1.4 Related documents ............................................ 5 1.5 Definitions ................................................ 5 1.6 Translations ................................................ 6 2 The Debian Archive 7 2.1 The Debian Free Software Guidelines .................................. 7 2.2 Archive areas ............................................... 8 2.2.1 The main archive area ...................................... 8 2.2.2 The contrib archive area ..................................... 8 2.2.3 The non-free archive area .................................... 9 2.3 Copyright considerations ......................................... 9 2.4 Sections .................................................. 10 2.5 Priorities ................................................. 10 3 Binary packages 13 3.1 The package name ............................................ 13 3.1.1 Packages with potentially offensive content ........................... 13 3.2 The version of a package ......................................... 14 3.2.1
    [Show full text]
  • Ubuntu-Packaging-Guide.Pdf
    Ubuntu Packaging Guide Release 1.0.3 bzr711 ubuntu14.04.1 Ubuntu Developers August 31, 2021 CONTENTS 1 Articles 2 1.1 Introduction to Ubuntu Development..................................2 1.2 Getting Set Up..............................................4 1.3 Fixing a bug in Ubuntu..........................................8 1.4 Packaging New Software......................................... 14 1.5 Security and Stable Release Updates.................................. 17 1.6 Patches to Packages........................................... 19 1.7 Fixing FTBFS packages......................................... 22 1.8 Shared Libraries............................................. 23 1.9 Backporting software updates...................................... 25 2 Knowledge Base 26 2.1 Communication in Ubuntu Development................................ 26 2.2 Basic Overview of the debian/ Directory............................... 26 2.3 ubuntu-dev-tools: Tools for Ubuntu developers............................. 32 2.4 autopkgtest: Automatic testing for packages.............................. 34 2.5 Using Chroots.............................................. 36 2.6 Setting up sbuild............................................. 37 2.7 KDE Packaging............................................. 40 3 Further Reading 42 i CONTENTS Ubuntu Packaging Guide Welcome to the Ubuntu Packaging and Development Guide! This is the official place for learning all about Ubuntu Development and packaging. After reading this guide you will have: • Heard about the most important players,
    [Show full text]
  • Debian Packaging Tutorial
    Debian Packaging Tutorial Lucas Nussbaum [email protected] version 0.16 – 2015-09-11 Debian Packaging Tutorial 1 / 51 About this tutorial I Goal: tell you enough about Debian packaging to get started I Modify existing packages (porting, bugfixing) I Create your own packages I Interact with the Debian community I Covers the most important points, but is not complete I You will need to read more documentation I Most of the content also applies to Debian derivative distributions I That includes Ubuntu Debian Packaging Tutorial 2 / 51 Outline 1 Introduction 2 Creating source packages 3 Building and testing packages 4 Advanced packaging topics 5 Maintaining packages in Debian 6 Conclusions Debian Packaging Tutorial 3 / 51 Outline 1 Introduction 2 Creating source packages 3 Building and testing packages 4 Advanced packaging topics 5 Maintaining packages in Debian 6 Conclusions Debian Packaging Tutorial 4 / 51 Debian packages I .deb files (binary packages) I A very powerful and convenient way to distribute software to users Dependencies, manifests, versioning, configuration, setup scripts I One of the two most common package formats (with RPM) I Useful for internal projects as well as distros I Universal: I 40,000 binary packages in Debian ! most of the available free software is packaged in Debian! I For 10 release ports (architectures) (10 more built, including 2 non-Linux (Hurd; KFreeBSD) I Also used by 120 Debian derivative distributions Debian Packaging Tutorial 5 / 51 The Deb package format I .deb file: an ar archive $ ar tv wget_1.12-2.1_i386.deb rw-r--r-- 0/0 4 Sep 5 15:43 2010 debian-binary rw-r--r-- 0/0 2403 Sep 5 15:43 2010 control.tar.gz rw-r--r-- 0/0 751613 Sep 5 15:43 2010 data.tar.gz I debian-binary: version of the deb file format, "2.0\n" I control.tar.gz: metadata about the package control, md5sums, (pre|post)(rm|inst), triggers, shlibs,..
    [Show full text]
  • Debreate Usage Version 0.3
    Debreate Usage Version 0.3 Contents 1 Section 1 – Introduction 1.1 Disclaimer 1.2 Packages and Package Managers 1.3 Binary Packages 1.4 Debreate 2 Section 2 – Using Debreate 2.1 Menu Bar and Basic Usage 2.2 Control 2.3 Dependencies and Conflicts 2.4 Files 2.5 Scripts 2.6 Changelog 2.7 Copyright 2.8 Menu Launcher 2.9 Build 2.10 Quick Build 3 Section 3 3.1 Credits 3.2 License 3.3 Reference Section 1 – Introduction Disclaimer This usage documentation is comprised of what I know about the Debian packaging system and what I have been able to decipher from the Debian Policy Manual. If any mistakes are found herein, please notify the development team (a.k.a. me) and we will investigate whether the issue needs to be addressed or not. I am not accountable for any mistakes or misinformation within this usage document, but I am willing to make corrections. Some information has been gathered from the Debian and Ubuntu policy manuals. Any text appearing to be taken directly from those sites falls under the pertaining licenses. Packages and Package Managers Most Linux and BSD based operating systems use package managers to install and organize software. This software is bundled in packages which are compressed archives. Debian based systems generally use the Debian Package Management System (dpkg) and the Advanced Packaging Tool (apt) or Aptitude for package management. There are also GUI frontends like Synaptic that can be used as well. Binary Packages Debian (deb) packages are Unix ar (a.k.a The Archiver) archive files.
    [Show full text]
  • Multiarch - What Is It and Why Should I Care?
    Multiarch - what is it and why should I care? Wookey Linaro and Debian 25th April 2014 openSUSE Conference Dubrovnik, Croatia Wookey Multiarch - what is it and why should I care? oSC 2014, Dubrovnik 1 / 40 Who am I Free Software developer since 1990 Unix sysadmin since 1996 Arm Linux developer since 1999 Debian developer since 2000 Ubuntu development since 2010 Currently an ARM secondee to Linaro Here for some cross-distro de-siloing Some things I had something to do with: Survex, PsiLinux, ArmLinux book, Emdebian, bootfloppies, Therion, apt-cross, dpkg-cross, Debian cross-toolchains, OpenEmbedded, Netbook Project, LART, YAFFS, Debian armel and arm64 ports, Balloonboard, xdeb, multiarch, sbuild, build profiles Wookey Multiarch - what is it and why should I care? oSC 2014, Dubrovnik 2 / 40 Wookey Multiarch - what is it and why should I care? oSC 2014, Dubrovnik 3 / 40 Mulitarch Technical: I What is it? I What does it do? I How does it work? Social: I Is it important? I What's it like making big changes like this? I What did we learn from the excercise? Wookey Multiarch - what is it and why should I care? oSC 2014, Dubrovnik 4 / 40 Nomenclature Build : Machine/architecture you are building on Host : Machine/architecture package is being built for Target : Machine/architecture a compiler generates code for Wookey Multiarch - what is it and why should I care? oSC 2014, Dubrovnik 5 / 40 Outline 1 Multiarch: What it is 2 Multiarch: What it does 3 Multiarch: How it works 4 Multiarch History 5 The Process Wookey Multiarch - what is it and why should I care? oSC 2014, Dubrovnik 6 / 40 What is Multiarch? Multiarch is a general mechanism for installing libraries of more than one architecture (ABI) on a system more general than /lib,/lib64 simple enough in principle .
    [Show full text]
  • Obs-User-Guide.Pdf
    User Guide User Guide: Open Build Service Publication Date: 09/28/2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see http://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About this Guide xiii 1 Available Documentation xiii 2 Feedback xiii 3 Documentation Conventions xiv 4 Contributing to the Documentation xv I FIRST STEPS 1 1 Beginnerʼs Guide 2 1.1 Target Audience 2 1.2 Conceptual Overview 2 Build Recipe 3 • Build Hosts and Packages 3 • Projects and Packages 4 1.3 Requirements for Working with the osc Command-Line Tool 5 1.4 Covered Scenarios 5 1.5 Configuring Your System for OBS 6 1.6 Setting Up Your Home Project for
    [Show full text]