RTEMS 4.11.3 User Manual.¶
Table of Contents¶
1. Overview¶
Welcome to the RTEMS User Manual.
This document covers the topics a user of RTEMS needs to be able to install, configure, build and create applications for the RTEMS operating system.
RTEMS, Real-Time Executive for Multiprocessor Systems, is a real-time executive (kernel) which provides a high performance environment for embedded applications with the following features:
- standards based user interfaces
- multitasking capabilities
- homogeneous and heterogeneous multiprocessor systems
- event-driven, priority-based, preemptive scheduling
- optional rate monotonic scheduling
- intertask communication and synchronization
- priority inheritance
- responsive interrupt management
- dynamic memory allocation
- high level of user configurability
- open source with a friendly user license
RTEMS provides features found in modern operating systems:
- file systems
- networking
- USB
- permanent media such as flash disks, cards and USB devices
- support for various languages
- parallel programming language support
1.1. Real-time Application Systems¶
Real-time application systems are a special class of computer applications. They have a complex set of characteristics that distinguish them from other software problems. Generally, they must adhere to more rigorous requirements. The correctness of the system depends not only on the results of computations, but also on the time at which the results are produced. The most important and complex characteristic of real-time application systems is that they must receive and respond to a set of external stimuli within rigid and critical time constraints referred to as deadlines. Systems can be buried by an avalanche of interdependent, asynchronous or cyclical event streams.
Deadlines can be further characterized as either hard or soft based upon the value of the results when produced after the deadline has passed. A deadline is hard if the results have no value after the deadline has passed, or a catastophic event results from their intended use if not completed on time. In contrast, results produced after a soft deadline may still have some value.
Another distinguishing requirement of real-time application systems is the ability to coordinate or manage a large number of concurrent activities. Since software is a synchronous entity, this presents special problems. One instruction follows another in a repeating synchronous cycle. Even though mechanisms have been developed to allow for the processing of external asynchronous events, the software design efforts required to process and manage these events and tasks are growing more complicated.
The design process is complicated further by spreading this activity over a set of processors instead of a single processor. The challenges associated with designing and building real-time application systems become very complex when multiple processors are involved. New requirements such as interprocessor communication channels and global resources that must be shared between competing processors are introduced. The ramifications of multiple processors complicate each and every characteristic of a real-time system.
1.2. Real-time Executive¶
Fortunately, real-time operating systems, or real-time executives, serve as a cornerstone on which to build the application system. A real-time multitasking executive allows an application to be cast into a set of logical, autonomous processes or tasks which become quite manageable. Each task is internally synchronous, but different tasks execute independently, resulting in an asynchronous processing stream. Tasks can be dynamically paused for many reasons resulting in a different task being allowed to execute for a period of time. The executive also provides an interface to other system components such as interrupt handlers and device drivers. System components may request the executive to allocate and coordinate resources, and to wait for and trigger synchronizing conditions. The executive system calls effectively extend the CPU instruction set to support efficient multitasking. By causing tasks to travel through well-defined state transitions, system calls permit an application to demand-switch between tasks in response to real-time events.
By properly grouping stimuli responses into separate tasks a system can now asynchronously switch between independent streams of execution. This allows the system to directly respond to external stimuli as they occur, as well as meet critical performance specifications that are typically measured by guaranteed response time and transaction throughput. The multiprocessor extensions of RTEMS provide the features necessary to manage the extra requirements introduced by a system distributed across several processors. It removes the physical barriers of processor boundaries from the world of the system designer, enabling more critical aspects of the system to receive the required attention. Such a system, based on an efficient real-time, multiprocessor executive, is a more realistic model of the outside world or environment for which it is designed. As a result, the system will always be more logical, efficient, and reliable.
By using the directives provided by RTEMS, the real-time applications developer is freed from the problem of controlling and synchronizing multiple tasks and processors. In addition, one need not develop, test, debug, and document routines to manage memory, pass messages, or provide mutual exclusion. The developer is then able to concentrate solely on the application. By using standard software components, the time and cost required to develop sophisticated real-time applications is significantly reduced.
2. RTEMS Ecosystem¶
The RTEMS Ecosystem is the collection of tools, packages, code, documentation and online content provided by the RTEMS Project. The ecosystem provides a way to develop, maintain, and use RTEMS. It’s parts interact with the user, the host environment, and each other to make RTEMS accessable, useable and predicable.
The ecosystem is for users, developers and maintainers and it is an on going effort that needs your help and support. The RTEMS project is always improving the way it delivers the kernel to you and your feedback is important so please join the mailing lists and contribute back comments, success stories, bugs and patches.
What the RTEMS project describes here to develop, maintain and use RTEMS does not dictate what you need to use in your project. You can and should select the work-flow that best suites the demands of your project and what you are delivering.
2.1. Rational¶
RTEMS is complex and the focus of the RTEMS Ecosystem is to simplify the complexity for users by providing a stable documented way to build, configure and run RTEMS. RTEMS is more than a kernel running real-time applications on target hardware, it is part of a project’s and therefore team’s workflow and every project and team is different.
RTEMS’s ecosystem does not mandate a way to work. It is a series of parts, components, and items that are used to create a suitable development environment to work with. The processes explained in this manual are the same things an RTEMS maintainer does to maintain the kernel or an experienced user does to build their production system. It is important to keep this in mind when working through this manual. We encourage users to explore what can be done and to discover ways to make it fit their needs. The ecosystem provided by the RTEMS Project will not install in a single click of a mouse because we want users to learn the parts they will come to depend on as their project’s development matures.
The RTEMS Ecosystem provides a standard interface that is the same on all supported host systems. Standardizing how a user interacts with RTEMS is important and making that experience portable is also important. As a result the ecosystem is documented at the command line level and we leave GUI and IDE integration for users and integrators.
Standardizing the parts and how to use them lets users create processes and procedures that are stable over releases. The RTEMS Ecosystem generates data that can be used to audit the build process so their configuration can be documented.
The ecosystem is based around the source code used in the various parts, compontents and items of the RTEMS development environment. A user can create an archive of the complete build process including all the source code for long term storage. This is important for projects with a long life cycle.
2.2. Open Source¶
RTEMS is an open source operating system and an open source project and this extends to the ecosystem. We encourage users to integrate the processes to build tools, the kernel and any 3rd party libraries into their project’s configuration management processes.
All the parts that make up the ecosystem are open source. The ecosystem uses a package’s source code to create an executable on a host so when an example RTEMS executable is created and run for the first time the user will have built every tool as well as the executable from source. The RTEMS Project believes the freedom this gives a user is as important as the freedom of having access to the source code for a package.
2.3. Deployment¶
The RTEMS Project provides the ecosystem as source code that users can download to create personalised development environments. The RTEMS Project does not provide packaging and deployment for a specific host environment, target architecture or BSP. The RTEMS Project encourages users and organizations to fill this role for the community.
3. Quick Start¶
The following is a quick start guide that provides a basic set of commands to build the RTEMS Tools and Kernel. The quick start guide provides links to the detailed sections if any problems are encoutnered.
The detailed procedure for installing RTEMS can be found in Chapter 5 - Installation.
The development host computer needs to be set up for this quick start procedure to complete successfully. Chapter 4 - Host Computer details what is needed for the supported host operating systems. If Windows is being used it is recommended following the procedure in Chapter 4 Section 4 - Microsoft Windows first.
Their are many ways and locations a suitable environment can be set up. A common factor that defines the final location of tools and projects is the place you have suitable storage. Chapter 5 Section 1 - Prefixes and Chapter 5 Section 1.1 - Project Sandboxing provide detailed examples of possible locations and set ups .
This procedure installs a developer set up using the RTEMS Git repositories on a Unix (POSIX) or MacOS host. The output from the commands has been removed and replaced with ....
Create a workspace, download the RTEMS Source Builder (RSB) and build a tool chain (Chapter 5 Section 3.1 - POSIX and OS X Host Tools Chain):
$ cd
$ mkdir -p development/rtems
$ cd development/rtems
$ git clone git://git.rtems.org/rtems-source-builder.git rsb
...
$ cd rsb
$ ./source-builder/sb-check
...
$ cd rtems
$ ../source-builder/sb-set-builder \
--prefix=/usr/home/chris/development/rtems/4.12 4.12/rtems-sparc
...
Build the RTEMS Kernel (Chapter 5 Section 3.2.2 - Building the Kernel) by cloning the repository, running the bootstrap procecure, building and finally installing the kernel:
$ export PATH=$HOME/development/rtems/4.12/bin:$PATH
$ cd
$ cd development/rtems
$ mkdir kernel
$ cd kernel
$ git clone git://git.rtems.org/rtems.git rtems
...
$ cd rtems
$ ./bootstrap -c && ./bootstrap -p && \
$HOME/development/rtems/rsb/source-builder/sb-bootstrap
...
$ cd ..
$ mkdir erc32
$ cd erc32
$ $HOME/development/rtems/kernel/rtems/configure --prefix=$HOME/development/rtems/4.12 \
--target=sparc-rtems4.12 --enable-rtemsbsp=erc32 --enable-posix
...
$ make -j 8
...
$ make install
You can now build a 3rd party library or an application.
4. Host Computer¶
RTEMS applications are developed using cross-development tools running on a development computer, more often called the host computer. These are typically your desktop machine or a special build server. All RTEMS tools and runtime libraries are built from source on your host machine. The RTEMS Project does not maintain binary builds of the tools. This differs to what you normally experience with host operating systems, and it is, however this approach works well. RTEMS is not a host operating system and it is not a distrbution. Deploying binary packages for every possible host operating system is too big a task for the RTEMS Project and it is not a good use of core developer time. Their time is better spent making RTEMS better and faster.
The RTEMS Project’s aim is to give you complete freedom to decide on the languages used in your project, which version control system, and the build system for your application.
The rule for selecting a computer for a developer is more is better but we do understand there are limits. Projects set up different configurations, some have a development machine per developer while others set up a tightly controlled central build server. RTEMS Ecosystem is flexible and lets you engineer a development environment that suites you. The basic specs are:
- Multicore processor
- 8G bytes RAM
- 256G harddisk
RTEMS makes no demands on graphics.
If you are using a VM or your host computer is not a fast modern machine do not be concerned. The tools may take longer to build than faster hardware however building tools is something you do once. Once the tools and RTEMS is built all your time can be spent writing and developing your application. Over an hour can happen and for the ARM architecture and with all BSPs it can be many hours.
4.1. Host Operating Systems¶
A wide range of host operating systems and hardware can be used. The host operating systems supported are:
- Linux
- FreeBSD
- NetBSD
- Apple OS X
- Windows
- Solaris
The functionality on a POSIX operating such as Linux and FreeBSD is similar and most features on Windows are supported but you are best to ask on the Users Mailing List if you have a specific question.
We recommend you maintain your operating system by installing any updates.
4.2. POSIX Hosts¶
POSIX hosts are most Unix operating systems such as Linux, FreeBSD and NetBSD. RTEMS development works well on Unix and can scale from a single user and a desktop machine to a team with decentralised or centralised development infrastructure.
4.2.1. Root Access¶
You either have root access to your host development machine or you do not. Some users are given hardware that is centrally managed. If you do not have root access you can create your work environment in your home directory. You could use a prefix of $HOME/development/rtems or $HOME/rtems. Note, the $HOME environment variable can be substituted with ~.
Chapter 5 Section 1 - Prefixes details using Prefixes to manage the installation.
RTEMS Tools and packages do not require root access to be built and we encourage you to not build the tools as root. If you need to control write access then it is best to manage this with groups assigned to users.
If you have root access you can decide to install the tools under any suitable prefix. This may depend on the hardware in your host development machine. If the machine is a centralised build server the prefix may be used to separate production versions from the test versions and the prefix paths may have restricted access rights to only those who manage and have configuration control of the machine. We call this project sandboxing and Chapter 5 Section 1.1 - Project Sandboxing explains this in more detail.
4.3. Apple OS X¶
Apple’s OS X is fully supported. You need to download and install a recent version of the Apple developer application Xcode. Xocde is available in the App Store. Make sure you install the Command Line Tools add on available for download within Xcode and once installed open a Terminal shell and enter the command cc and accept the license agreement.
The normal prefix when working on OS X as a user is under your home directory. Prefixes of $HOME/development/rtems or $HOME/rtems are suitable.
Chapter 5 Section 1 - Prefixes details using Prefixes to manage the installation.
4.4. Microsoft Windows¶
RTEMS supports Windows as a development host and the tools for most architectures are available. The RTEMS Project relies on the GNU tools for compilers and debuggers and we use the simulators that come with GDB and QEMU. The Windows support for these tools varies and the RTEMS Project is committed to helping the open source community improve the Windows experience. If something is not working or supported please email the Users Mailing List.
The RTEMS Project’s Windows tools are native Windows executables giving the user the best possible experience on Windows. Native Windows programs use the standard Windows DLLs and paths. Integration with standard Windows integrated development tools such as editors is straight forward. POSIX emulation environments such as Cygwin and the MSYS2 shell have special executables that require a POSIX emulation DLL and these emulation DLLs add an extra layer of complexity as well as a performance over-head. The RTEMS Project uses these POSIX emulation shells to run configure scripts that come with various open source packages such as gcc so they form an important and valued part of the environment we describe here. The output of this procedure forms the tools you use during your application development and they do not depend on the emulation DLLs.
The performance of the compiler is as good as you can have on Windows and the performance compiling a single file will be similar to that on a host like Linux or FreeBSD given the same hardware. Building the tools from source is much slower on Windows because POSIX shells and related tools are used and the POSIX emulation overhead it much much slower than a native POSIX operating system like Linux and FreeBSD. This overhead is only during the building of the tools and the RTEMS kernel and if you use a suitable build system that is native to Windows your application development should be similar to other operating systems.
Building is known to work on Windows 7 64bit Professional and Windows 10.
4.4.1. Windows Path Length¶
Windows path length is limited and can cause problems when building the tools. The standard Windows API has a MAX_PATH length of 260 characters. This can effect some of the tools used by RTEMS. It is recommended you keep the top level directories as short as possible when building the RTEMS tools and you should also keep an eye on the path length when developing your application. The RTEMS built tools can handle much longer path lengths however some of the GNU tools such as those in the binutils package cannot.
The release packages of the RSB when unpacked have top level file names that are too big to build RTEMS. You need to change or rename that path to something smaller to build. This is indicated in Chapter 5 Section 2 - Releases.
4.4.2. Parallel Builds with Make¶
The MSYS2 GNU make has problems when using the jobs option. The RSB defaults to automatically using as many cores as the host machine has. To get a successful build on Windows it is recommended you add the --jobs=none option to all RSB build set commands.
4.4.3. POSIX Support¶
Building the RTEMS compilers, debugger, the RTEMS kernel and a number of other 3rd party packages requires a POSIX environment. On Windows you can use Cygwin or MSYS2. This document focuses on MSYS2. It is smaller than Cygwin and comes with the Arch Linux package manager pacman.
MSYS2 provides MinGW64 support as well as a POSIX shell called MSYS2. The MinGW64 compiler and related tools produce 64bit native Windows executables. The shell is a standard Bourne shell and the MSYS2 environment is a stripped Cygwin shell with enough support to run the various configure scripts needed to build the RTEMS tools and the RTEMS kernel.
MSYS2 is built around the pacman packaging tool. This makes MSYS2 a distribution and that is a welcome feature on Windows. You get a powerful tool to manage your development environment on Windows.
4.4.4. Python¶
We need Python to build the tools as the RSB is written in Python and we need suitable Python libraries to link to GDB as RTEMS makes use of GDB’s Python support. This places specific demands on the Python we need installed and available and MSYS2 provides suitable Python versions we can use. You need to make sure you have the correct type and version of Python installed.
We cannot use the Python executables created by the Python project (python.org) as they are built by Microsoft’s C (MSC) compiler. Linking the MSC Python libraries with the MinGW64 executables is not easy and MSYS provides us with a simple solution so we do not support linking MSC libraries.
MSYS2 provides two types and two versions of Python executables, MinGW and MSYS and Python version 2 and 3. For Windows we need the MinGW executable so we have suitables libraries and we have to have Python version 2 because on Windows GDB only builds with Python2.
You also need to install the MSYS version of Python along with the MinGW64 Python2 package. The MSYS Python is version 3 and the RSB can support version 2 and 3 of Python and it helps handle some of the long paths building GCC can generate.
4.4.5. Installing MSYS2¶
MSYS2 is installed on a new machine using the MSYS2 installer found on https://msys2.github.io/. Please select the x86_64 variant for 64bit support. Run the installer following the 7 steps listed on the page.
MSYS2 uses the pacman package manager. The Arch Linux project has detailed documentation on how to use pacman. What is shown here is a just few examples of what you can do.
Open a 64bit MSYS shell from the Start Menu:
The packages we require are:
- python
- mingw-w64-x86_64-python2
- mingw-w64-x86_64-gcc
- git
- bison
- cvs
- diffutils
- make
- patch
- tar
- texinfo
- unzip
Note
The actual output provided may vary due to changes in the dependent packages or newer package versions.
Install the packages using pacman:
~
$ pacman -S python mingw-w64-x86_64-python2 mingw-w64-x86_64-gcc \
bison cvs diffutils git make patch tar texinfo unzip
resolving dependencies...
looking for conflicting packages...
Packages (74) db-5.3.28-2 expat-2.1.0-2 gdbm-1.11-3 heimdal-1.5.3-8
libgdbm-1.11-3 mingw-w64-x86_64-binutils-2.26-21
mingw-w64-x86_64-bzip2-1.0.6-5
mingw-w64-x86_64-ca-certificates-20150426-2
mingw-w64-x86_64-crt-git-5.0.0.4627.03684c4-1
mingw-w64-x86_64-expat-2.1.0-6 mingw-w64-x86_64-gcc-libs-5.3.0-2
mingw-w64-x86_64-gdbm-1.11-3 mingw-w64-x86_64-gettext-0.19.6-2
mingw-w64-x86_64-gmp-6.1.0-1
mingw-w64-x86_64-headers-git-5.0.0.4627.53be55d-1
mingw-w64-x86_64-isl-0.15-1 mingw-w64-x86_64-libffi-3.2.1-3
mingw-w64-x86_64-libiconv-1.14-5
mingw-w64-x86_64-libsystre-1.0.1-2
mingw-w64-x86_64-libtasn1-4.7-1
mingw-w64-x86_64-libtre-git-r122.c2f5d13-4
mingw-w64-x86_64-libwinpthread-git-5.0.0.4573.628fdbf-1
mingw-w64-x86_64-mpc-1.0.3-2 mingw-w64-x86_64-mpfr-3.1.3.p0-2
mingw-w64-x86_64-ncurses-6.0.20160220-2
mingw-w64-x86_64-openssl-1.0.2.g-1
mingw-w64-x86_64-p11-kit-0.23.1-3
mingw-w64-x86_64-readline-6.3.008-1 mingw-w64-x86_64-tcl-8.6.5-1
mingw-w64-x86_64-termcap-1.3.1-2 mingw-w64-x86_64-tk-8.6.5-1
mingw-w64-x86_64-windows-default-manifest-6.4-2
mingw-w64-x86_64-winpthreads-git-5.0.0.4573.628fdbf-1
mingw-w64-x86_64-zlib-1.2.8-9 openssh-7.1p2-1 perl-5.22.0-2
perl-Authen-SASL-2.16-2 perl-Convert-BinHex-1.123-2
perl-Encode-Locale-1.04-1 perl-Error-0.17024-1
perl-File-Listing-6.04-2 perl-HTML-Parser-3.71-3
perl-HTML-Tagset-3.20-2 perl-HTTP-Cookies-6.01-2
perl-HTTP-Daemon-6.01-2 perl-HTTP-Date-6.02-2
perl-HTTP-Message-6.06-2 perl-HTTP-Negotiate-6.01-2
perl-IO-Socket-SSL-2.016-1 perl-IO-stringy-2.111-1
perl-LWP-MediaTypes-6.02-2 perl-MIME-tools-5.506-1
perl-MailTools-2.14-1 perl-Net-HTTP-6.09-1
perl-Net-SMTP-SSL-1.02-1 perl-Net-SSLeay-1.70-1
perl-TermReadKey-2.33-1 perl-TimeDate-2.30-2 perl-URI-1.68-1
perl-WWW-RobotRules-6.02-2 perl-libwww-6.13-1 vim-7.4.1468-1
bison-3.0.4-1 cvs-1.11.23-2 diffutils-3.3-3 git-2.7.2-1
make-4.1-4 mingw-w64-x86_64-gcc-5.3.0-2
mingw-w64-x86_64-python2-2.7.11-4 patch-2.7.5-1 python-3.4.3-3
tar-1.28-3 texinfo-6.0-1 unzip-6.0-2
Total Download Size: 114.10 MiB
Total Installed Size: 689.61 MiB
:: Proceed with installation? [Y/n] y
:: Retrieving packages...
mingw-w64-x86_64-gm... 477.1 KiB 681K/s 00:01 [#####################] 100%
mingw-w64-x86_64-li... 24.2 KiB 755K/s 00:00 [#####################] 100%
mingw-w64-x86_64-gc... 541.9 KiB 705K/s 00:01 [#####################] 100%
mingw-w64-x86_64-ex... 106.7 KiB 702K/s 00:00 [#####################] 100%
mingw-w64-x86_64-bz... 77.9 KiB 666K/s 00:00 [#####################] 100%
mingw-w64-x86_64-li... 600.2 KiB 703K/s 00:01 [#####################] 100%
mingw-w64-x86_64-ge... 3.0 MiB 700K/s 00:04 [#####################] 100%
mingw-w64-x86_64-gd... 151.8 KiB 483K/s 00:00 [#####################] 100%
mingw-w64-x86_64-li... 34.5 KiB 705K/s 00:00 [#####################] 100%
mingw-w64-x86_64-li... 69.2 KiB 713K/s 00:00 [#####################] 100%
mingw-w64-x86_64-li... 9.3 KiB 778K/s 00:00 [#####################] 100%
mingw-w64-x86_64-nc... 1800.5 KiB 701K/s 00:03 [#####################] 100%
mingw-w64-x86_64-li... 171.4 KiB 708K/s 00:00 [#####################] 100%
mingw-w64-x86_64-p1... 193.5 KiB 709K/s 00:00 [#####################] 100%
mingw-w64-x86_64-ca... 382.1 KiB 705K/s 00:01 [#####################] 100%
mingw-w64-x86_64-zl... 148.6 KiB 704K/s 00:00 [#####################] 100%
mingw-w64-x86_64-op... 3.3 MiB 624K/s 00:05 [#####################] 100%
mingw-w64-x86_64-te... 12.6 KiB 76.7K/s 00:00 [#####################] 100%
mingw-w64-x86_64-re... 327.4 KiB 277K/s 00:01 [#####################] 100%
mingw-w64-x86_64-tc... 2.9 MiB 699K/s 00:04 [#####################] 100%
mingw-w64-x86_64-tk... 1869.2 KiB 703K/s 00:03 [#####################] 100%
mingw-w64-x86_64-py... 10.9 MiB 699K/s 00:16 [#####################] 100%
mingw-w64-x86_64-bi... 12.7 MiB 688K/s 00:19 [#####################] 100%
mingw-w64-x86_64-he... 5.0 MiB 645K/s 00:08 [#####################] 100%
mingw-w64-x86_64-cr... 2.6 MiB 701K/s 00:04 [#####################] 100%
mingw-w64-x86_64-is... 524.3 KiB 684K/s 00:01 [#####################] 100%
mingw-w64-x86_64-mp... 265.2 KiB 705K/s 00:00 [#####################] 100%
mingw-w64-x86_64-mp... 62.3 KiB 82.9K/s 00:01 [#####################] 100%
mingw-w64-x86_64-wi... 1484.0 B 0.00B/s 00:00 [#####################] 100%
mingw-w64-x86_64-wi... 33.2 KiB 346K/s 00:00 [#####################] 100%
mingw-w64-x86_64-gc... 25.1 MiB 701K/s 00:37 [#####################] 100%
python-3.4.3-3-x86_64 12.1 MiB 700K/s 00:18 [#####################] 100%
bison-3.0.4-1-x86_64 1045.1 KiB 703K/s 00:01 [#####################] 100%
heimdal-1.5.3-8-x86_64 543.7 KiB 703K/s 00:01 [#####################] 100%
cvs-1.11.23-2-x86_64 508.2 KiB 388K/s 00:01 [#####################] 100%
diffutils-3.3-3-x86_64 265.7 KiB 478K/s 00:01 [#####################] 100%
expat-2.1.0-2-x86_64 13.1 KiB 817K/s 00:00 [#####################] 100%
vim-7.4.1468-1-x86_64 6.1 MiB 700K/s 00:09 [#####################] 100%
openssh-7.1p2-1-x86_64 653.4 KiB 703K/s 00:01 [#####################] 100%
db-5.3.28-2-x86_64 41.7 KiB 719K/s 00:00 [#####################] 100%
libgdbm-1.11-3-x86_64 20.4 KiB 754K/s 00:00 [#####################] 100%
gdbm-1.11-3-x86_64 108.5 KiB 704K/s 00:00 [#####################] 100%
perl-5.22.0-2-x86_64 12.4 MiB 702K/s 00:18 [#####################] 100%
perl-Error-0.17024-... 17.1 KiB 742K/s 00:00 [#####################] 100%
perl-Authen-SASL-2.... 42.4 KiB 731K/s 00:00 [#####################] 100%
perl-Encode-Locale-... 9.7 KiB 745K/s 00:00 [#####################] 100%
perl-HTTP-Date-6.02... 8.6 KiB 784K/s 00:00 [#####################] 100%
perl-File-Listing-6... 7.7 KiB 769K/s 00:00 [#####################] 100%
perl-HTML-Tagset-3.... 10.3 KiB 732K/s 00:00 [#####################] 100%
perl-HTML-Parser-3.... 76.9 KiB 516K/s 00:00 [#####################] 100%
perl-LWP-MediaTypes... 18.0 KiB 752K/s 00:00 [#####################] 100%
perl-URI-1.68-1-any 75.6 KiB 609K/s 00:00 [#####################] 100%
perl-HTTP-Message-6... 71.3 KiB 625K/s 00:00 [#####################] 100%
perl-HTTP-Cookies-6... 20.4 KiB 499K/s 00:00 [#####################] 100%
perl-HTTP-Daemon-6.... 14.2 KiB 749K/s 00:00 [#####################] 100%
perl-HTTP-Negotiate... 11.4 KiB 817K/s 00:00 [#####################] 100%
perl-Net-HTTP-6.09-... 19.8 KiB 732K/s 00:00 [