Void linux deb package

Void Linux. Управление пакетами. Система XBPS: интермедия о пакетах non-free

Как было сказано в предыдущем очерке, для многих применителей при выборе дистрибутива весьма важна доступность в его официальных репозиториях так называемых «несвободных» пакетов. Поэтому, забегая вперёд, в этой интермедии я коснусь данного вопроса.

Чаще всего интерес вызывают такие «не совсем свободные» программы, как фирменные видеодрайверы от AMD и Nvidia, Adobe Flash, Skype. Для использования в профессиональных целях многим требуются такие инструменты, как текстовые редакторы Sublime Text и/или Atom, Java в реализации от Oracle. Наконец, есть и такие, кто интересуется игрушками, типа легендарных Doom и Quake, или, напротив, пресловутого Steam.

В сети можно наткнуться на утверждения, что репозитории дистрибутива Void содержат только абсолютно свободные пакеты. И потому ничего подобного там нет и быть не может. Поначалу я и сам так думал — тем более, что ничего из перечисленного мне не нужно ни по жизни, ни по работе. Однако проведённое по наводке Stanis’а aka Станислав Шрамко следствие показало, что в Void’е имеется даже два репозитория типа non-free , с обычными и multilib-пакетами..

В очерке про репозитории говорится, что подключаются путём установки соответствующего пакета. А имена пакетов, которые должны фигурировать как аргументы команды инсталляции, выявляются так:

Я для начала ограничился вторым пакетом, так как испытываю некоторое недоверие к multilib-пакетам (признаюсь, ни на чём особо не основанное, кроме общих соображений):

Далее выполняется синхронизация:

И можно приступать к «проверке на вшивость». Начав с вещей, которые действительно могут быть нужны по делу — например, фирменных драйверов, ибо видеочипы «последнего розливу» от AMD и особенно Nvidia не всегда поддерживаются соответствующими свободными драйверами.

оказывается очень длинным:

Видеокарт с чипами этой фирмы у меня не было давно, и потому я не могу сказать, всё ли тут есть, что нужно для счастья, и первой ли оно свежести (или, наоборот, последней — для «счастливых» обладателей видеокарт старых). Однако обращает внимание наличие bumblebee для поддержки так называемой технологии Optimus, не к ночи будь помянута.

С видеочипами от AMD всё гораздо компактней,

И здесь, насколько я помню, имеется всё необходимое — по крайней мере, для работы с AMD APU, дискретных видеокарт на чипах этой фирмы у меня тоже давно не было.

Теперь текстовые редакторы — любителей Sublime Text оказалось довольно много, а Atom интересен концептуально, хотя пока и выглядит «недоношенным». Так что — делай раз:

Кстати, самого Google Chrome ни в одном репозитории нет. Но в главной ветке имеется Chromium, о чём я не так давно упоминал.

И последнее из «профнабора»:

Теперь займёмся поисками «парнухи», начиная с Adobe Flash, которая иногда нужна и для мирных целей, например, вывода результатов измерений в реальном времени. И оказывается, что их у Void’а есть (хотя, кажется, и старой версии):

А заодно обнаруживается и чуть «менее несвободный» аналог:

А вот со Skype с первой попытки — облом: команда

возвращает пустую командную строку, свидетельствующую об отсутствии такого пакета в подключённых репозиториях. Обидно, досадно… не за себя (я им не пользуюсь) — за державу дистрибутив. Но тут я вспоминаю, что, когда единственный раз я этот самый Skype устанавливал, он потянул за собой кучу 32-битного мусора. И решаю подключить репозиторий multilib-nonfree :

И теперь повторение команды

выдаёт на гора неизменно превосходный результат:

Так что мнение об отсутствии в Void всяческой проприетарной «парнухи» выглядит несколько преувеличенным.

Источник

Repositories

Repositories are the heart of the XBPS package system. Repositories can be local or remote. A repository contains binary package files, which may have signatures, and a data file named $ARCH-repodata (e.g. x86_64-repodata ), which may also be signed.

Note that, while local repositories do not require signatures, remote repositories must be signed.

The main repository

The locations of the main repository in relation to a base mirror URL are:

• glibc: /current
• musl: /current/musl
• aarch64 and aarch64-musl: /current/aarch64

Subrepositories

In addition to the main repository, which is enabled upon installation, Void provides other official repositories maintained by the Void project, but not enabled by default:

• nonfree: contains software packages with non-free licenses
• multilib: contains 32-bit libraries for 64-bit systems (glibc only)
• multilib/nonfree: contains non-free multilib packages
• debug: contains debugging symbols for packages

These repositories can be enabled via the installation of the relevant package. These packages only install a repository configuration file in /usr/share/xbps.d .

nonfree

Void has a nonfree repository for packages that don’t have free licenses. It can enabled by installing the void-repo-nonfree package.

Packages can end up in the nonfree repository for a number of reasons:

• Non-free licensed software with released source-code.
• Software released only as redistributable binary packages.
• Patented technology, which may or may not have an (otherwise) open implementation.

multilib

The multilib repository provides 32-bit packages as a compatibility layer inside a 64-bit system. It can be enabled by installing the void-repo-multilib package.

These repositories are only available for x86_64 systems running the glibc C library.

multilib/nonfree

The multilib/nonfree repository provides additional 32-bit packages which have non-free licenses. It can be enabled by installing the void-repo-multilib-nonfree package.

debug

Void Linux packages come without debugging symbols. If you want to debug software or look at a core dump you will need the debugging symbols. These packages are contained in the debug repository. It can be enabled by installing the void-repo-debug package.

Once enabled, symbols may be obtained for

Finding debug dependencies

The xtools package contains the xdbg(1) utility to retrieve a list of debug packages, including dependencies, for a package:

Источник

Installation

This section includes general information about the process of installing Void. For specific guides, see the «Advanced Installation» section.

Base system requirements

Void can be installed on very minimalist hardware, though we recommend the following minimums for most installations:

Architecture	CPU	RAM	Storage
x86_64-glibc	x86_64	96MB	700MB
x86_64-musl	x86_64	96MB	600MB
i686-glibc	Pentium 4 (SSE2)	96MB	700MB

Note that flavor installations require more resources; how much more depends on the flavor.

Void is not available for the i386, i486, or i586 architectures.

Before installing musl Void, please read the «musl» section of this Handbook, so that you are aware of software incompatibilities.

It is highly recommended to have a network connection available during install to download updates, but this is not required. ISO images contain installation data on-disk and can be installed without network connectivity.

Downloading installation media

The most recent live images and rootfs tarballs can be downloaded from https://alpha.de.repo.voidlinux.org/live/current/. They can also be downloaded from other mirrors. Previous releases can be found under https://alpha.de.repo.voidlinux.org/live/, organized by date.

Verifying images

Each image release’s directory contains two files used to verify the image(s) you download. First, there is a sha256sum.txt file containing image checksums to verify the integrity of the downloaded images. Second is the sha256sum.sig file, used to verify the authenticity of the checksums.

It is necessary to verify both the image’s integrity and authenticity. It is, therefore, recommended that you download both files.

Verifying image integrity

You can verify the integrity of a downloaded file using sha256sum(1) with the sha256sum.txt file downloaded above. The following command will check the integrity of only the image(s) you have downloaded:

This verifies that the image is not corrupt.

Verifying digital signature

Prior to using any image you’re strongly encouraged to validate the signatures on the image to ensure they haven’t been tampered with.

Current images are signed using a signify key that is specific to the release. If you’re on Void already, you can obtain the keys from the void-release-keys package, which will be downloaded using your existing XBPS trust relationship with your mirror. You will also need a copy of signify(1); on Void this is provided by the outils package.

To obtain signify when using a Linux distribution or operating system other than Void Linux:

• Install the signify package in Arch Linux and Arch-based distros.
• Install the signify-openbsd package in Debian and Debian-based distros.
• Install the package listed here for your distribution.
• Install signify-osx with homebrew in macOS.

If you can’t obtain signify for some reason (e.g. you are on Windows and can’t use WSL or MinGW), you can use minisign(1) to verify the file.

If you are not currently using Void Linux, it will also be necessary to obtain the appropriate signing key from our Git repository here.

Once you’ve obtained the key, you can verify your image with the sha256sum.sig file. The following example demonstrates the verification of the GCP musl filesystem from the 20191109 release:

If the verification process does not produce the expected «OK» status, do not use it! Please alert the Void Linux team of where you got the image and how you verified it, and we will follow up on it.

For verification with minisign , it is necessary to rename the sha256sum.sig file to sha256sum.txt.minisig and remove the first line from the .pub release key. The following example demonstrates the verification of the sha256sum.txt file from the 20191109 release:

The same warning as above applies. If the verification process isn’t successful, do not use the file — warn the Void Linux team about it.

Источник

Void linux deb package

All live images and rootfs tarballs are available at:

These files can also be downloaded from other mirrors, which are listed in the documentation. Simply navigate to live -> current to find them.

The requirements for these images can be found in the documentation. An internet connection via Ethernet or WiFi is required for network installation.

Verifying file integrity and its digital signature

It is strongly recommended to validate the integrity and authenticity of any downloaded image or tarball before using it, to ensure it hasn’t been tampered with. Instructions on how to do that are provided in the Void Handbook.

x86_64

Installable live images support a local installation (with the included packages) or a network installation (packages are downloaded from official repository).

You can log into these images as anon or root , and the password is voidlinux .

To start the installer, execute the void-installer utility with appropriate permissions (i.e., sudo void-installer ).

enlightenment

cinnamon

Installable live images support a local installation (with the included packages) or a network installation (packages are downloaded from official repository).

You can log into these images as anon or root , and the password is voidlinux .

To start the installer, execute the void-installer utility with appropriate permissions (i.e., sudo void-installer ).

enlightenment

cinnamon

ROOTFS tarballs can be extracted to a previously prepared partition scheme or used for chroot installation.

General and platform specific instructions are available in the documentation.

armv6l

armv7l

aarch64

arm platforms

Live images can be written onto an SD card (i.e. using dd ) and they provide you with a ready to boot system. These images are prepared for 2GB SD cards. Alternatively, use the ROOTFS tarballs if you want to customize the partitions and filesystems.

Connect to the system using a virtual terminal or SSH and log in as root with password voidlinux .

Platform specific instructions for these images are available in the documentation.

Deprecated instructions for the following platforms can be found in these wiki pages (you can help by porting them over to the Void Handbook):

Источник

Void linux deb package

The Void source packages collection

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

The XBPS source packages collection

This repository contains the XBPS source packages collection to build binary packages for the Void Linux distribution.

The included xbps-src script will fetch and compile the sources, and install its files into a fake destdir to generate XBPS binary packages that can be installed or queried through the xbps-install(1) and xbps-query(1) utilities, respectively.

See Contributing for a general overview of how to contribute and the Manual for details of how to create source packages.

Table of Contents

• GNU bash
• xbps >= 0.56
• git(1) — unless configured to not, see etc/defaults.conf
• common POSIX utilities included by default in almost all UNIX systems
• curl(1) — required by xbps-src update-check

For bootstrapping additionally:

• flock(1) — util-linux
• bsdtar or GNU tar (in that order of preference)
• install(1) — GNU coreutils
• objcopy(1), objdump(1), strip(1): binutils

xbps-src requires a utility to chroot and bind mount existing directories into a masterdir that is used as its main chroot directory. xbps-src supports multiple utilities to accomplish this task.

NOTE: xbps-src does not allow building as root anymore. Use one of the chroot methods.

Clone the void-packages git repository and install the bootstrap packages:

Build a package by specifying the pkg target and the package name:

Use ./xbps-src -h to list all available targets and options.

To build packages marked as ‘restricted’, modify etc/conf :

Once built, the package will be available in hostdir/binpkgs or an appropriate subdirectory (e.g. hostdir/binpkgs/nonfree ). To install the package:

Alternatively, packages can be installed with the xi utility, from the xtools package. xi takes the repository of the current working directory into account.

XBPS utility that uses user_namespaces(7) (part of xbps, default without -t flag).

This utility requires these Linux kernel options:

• CONFIG_NAMESPACES
• CONFIG_IPC_NS
• CONFIG_UTS_NS
• CONFIG_USER_NS

This is the default method, and if your system does not support any of the required kernel options it will fail with EINVAL (Invalid argument) .

XBPS utility that uses namespaces and must be setgid (part of xbps).

NOTE: This is the only method that implements functionality of xbps-src -t , therefore the flag ignores the choice made in configuration files and enables xbps-uchroot .

This utility requires these Linux kernel options:

• CONFIG_NAMESPACES
• CONFIG_IPC_NS
• CONFIG_PID_NS
• CONFIG_UTS_NS

Your user must be added to a special group to be able to use xbps-uchroot(1) and the executable must be setgid :

NOTE: by default in void you shouldn’t do this manually, your user must be a member of the xbuilder group.

If for some reason it’s erroring out as ERROR clone (Operation not permitted) , check that your user is a member of the required group and that xbps-uchroot(1) utility has the proper permissions and owner/group as explained above.

bubblewrap, sandboxing tool for unprivileged users that uses user namespaces or setuid. See https://github.com/containers/bubblewrap.

Destroys host system it runs on. Only useful for one-shot containers, i.e docker (used with CI).

Install the bootstrap packages

There is a set of packages that makes up the initial build container, called the bootstrap . These packages are installed into the masterdir in order to create the container.

The primary and recommended way to set up this container is using the binary-bootstrap command. This will use pre-existing binary packages, either from remote xbps repositories or from your local repository.

There is also the bootstrap command, which will build all necessary bootstrap packages from scratch. This is usually not recommended, since those packages are built using your host system’s toolchain and are neither fully featured nor reproducible (your host system may influence the build) and thus should only be used as a stage 0 for bootstrapping new Void systems.

If you still choose to use bootstrap , use the resulting stage 0 container to rebuild all bootstrap packages again, then use binary-bootstrap (stage 1) and rebuild the bootstrap packages once more (to gain stage 2, and then use binary-bootstrap again). Once you’ve done that, you will have a bootstrap set equivalent to using binary-bootstrap in the first place.

Also keep in mind that a full source bootstrap is time consuming and will require having an assortment of utilities installed in your host system, such as binutils , gcc , perl , texinfo and others.

The etc/defaults.conf file contains the possible settings that can be overridden through the etc/conf configuration file for the xbps-src utility; if that file does not exist, will try to read configuration settings from $XDG_CONFIG_HOME/xbps-src.conf ,

If you want to customize default CFLAGS , CXXFLAGS and LDFLAGS , don’t override those defined in etc/defaults.conf , set them on etc/conf instead i.e:

Native and cross compiler/linker flags are set per architecture in common/build-profiles and common/cross-profiles respectively. Ideally those settings are good enough by default, and there’s no need to set your own unless you know what you are doing.

The etc/defaults.virtual file contains the default replacements for virtual packages, used as dependencies in the source packages tree.

If you want to customize those replacements, copy etc/defaults.virtual to etc/virtual and edit it accordingly to your needs.

The following directory hierarchy is used with a default configuration file:

The description of these directories is as follows:

• masterdir : master directory to be used as rootfs to build/install packages.
• builddir : to unpack package source tarballs and where packages are built.
• destdir : to install packages, aka fake destdir.
• hostdir/ccache : to store ccache data if the XBPS_CCACHE option is enabled.
• hostdir/distcc- : to store distcc data if the XBPS_DISTCC option is enabled.
• hostdir/repocache : to store binary packages from remote repositories.
• hostdir/sources : to store package sources.
• hostdir/binpkgs : local repository to store generated binary packages.

The simplest form of building package is accomplished by running the pkg target in xbps-src :

When the package and its required dependencies are built, the binary packages will be created and registered in the default local repository at hostdir/binpkgs ; the path to this local repository can be added to any xbps configuration file (see xbps.d(5)) or by explicitly appending them via cmdline, i.e:

By default xbps-src will try to resolve package dependencies in this order:

• If a dependency exists in the local repository, use it ( hostdir/binpkgs ).
• If a dependency exists in a remote repository, use it.
• If a dependency exists in a source package, use it.

It is possible to avoid using remote repositories completely by using the -N flag.

The default local repository may contain multiple sub-repositories: debug , multilib , etc.

Package build options

The supported build options for a source package can be shown with xbps-src show-options :

Build options can be enabled with the -o flag of xbps-src :

Build options can be disabled by prefixing them with

Both ways can be used together to enable and/or disable multiple options at the same time with xbps-src :

The build options can also be shown for binary packages via xbps-query(1) :

NOTE: if you build a package with a custom option, and that package is available in an official void repository, an update will ignore those options. Put that package on hold mode via xbps-pkgdb(1) , i.e xbps-pkgdb -m hold foo to ignore updates with xbps-install -u . Once the package is on hold , the only way to update it is by declaring it explicitly: xbps-install -u foo .

Permanent global package build options can be set via XBPS_PKG_OPTIONS variable in the etc/conf configuration file. Per package build options can be set via XBPS_PKG_OPTIONS_

NOTE: if pkgname contains dashes , those should be replaced by underscores i.e XBPS_PKG_OPTIONS_xorg_server=opt .

The list of supported package build options and its description is defined in the common/options.description file or in the template file.

Sharing and signing your local repositories

To share a local repository remotely it’s mandatory to sign it and the binary packages stored on it. This is accomplished with the xbps-rindex(1) utility.

First a RSA key must be created with openssl(1) or ssh-keygen(1) :

Only RSA keys in PEM format are currently accepted by xbps.

Once the RSA private key is ready you can use it to initialize the repository metadata:

And then make a signature per package:

If —privkey is unset, it defaults to

If the RSA key was protected with a passphrase you’ll have to type it, or alternatively set it via the XBPS_PASSPHRASE environment variable.

Once the binary packages have been signed, check the repository contains the appropriate hex fingerprint :

Each time a binary package is created, a package signature must be created with —sign-pkg .

It is not possible to sign a repository with multiple RSA keys.

Rebuilding and overwriting existing local packages

Packages are overwritten on every build to make getting package with changed build options easy. To make xbps-src skip build and preserve first package build with with given version and revision, same as in official void repository, set XBPS_PRESERVE_PKGS=yes in etc/conf file.

Reinstalling a package in your target rootdir can be easily done too:

Using -f flag twice will overwrite configuration files.

Please note that the package expression must be properly defined to explicitly pick up the package from the desired repository.

Enabling distcc for distributed compilation

Setup the slaves (machines that will compile the code):

Modify the configuration to allow your local network machines to use distcc (e.g. 192.168.2.0/24 ):

Enable and start the distccd service:

Install distcc on the host (machine that executes xbps-src) as well. Unless you want to use the host as slave from other machines, there is no need to modify the configuration.

On the host you can now enable distcc in the void-packages/etc/conf file:

The example values assume a localhost CPU with 4 cores of which at most 2 are used for compiler jobs. The number of slots for preprocessor jobs is set to 24 in order to have enough preprocessed data for other CPUs to compile. The slave 192.168.2.101 has a CPU with 8 cores and the /9 for the number of jobs is a saturating choice. The slave 192.168.2.102 is set to run at most 2 compile jobs to keep its load low, even if its CPU has 4 cores. The XBPS_MAKEJOBS setting is increased to 16 to account for the possible parallelism (2 + 9 + 2 + some slack).

In etc/conf you may optionally define a mirror or a list of mirrors to search for distfiles.

If more than one mirror is to be searched, you can either specify multiple URLs separated with blanks, or add to the variable like this

Make sure to put the blank after the first double quote in this case.

The mirrors are searched in order for the distfiles to build a package until the checksum of the downloaded file matches the one specified in the template.

Ultimately, if no mirror carries the distfile, or in case all downloads failed the checksum verification, the original download location is used.

If you use uchroot for your XBPS_CHROOT_CMD, you may also specify a local path using the file:// prefix or simply an absolute path on your build host (e.g. /mnt/distfiles). Mirror locations specified this way are bind mounted inside the chroot environment under $XBPS_MASTERDIR and searched for distfiles just the same as remote locations.

Cross compiling packages for a target architecture

Currently xbps-src can cross build packages for some target architectures with a cross compiler. The supported target is shown with ./xbps-src -h .

If a source package has been adapted to be cross buildable xbps-src will automatically build the binary package(s) with a simple command:

If the build for whatever reason fails, might be a new build issue or simply because it hasn’t been adapted to be cross compiled.

Using xbps-src in a foreign Linux distribution

xbps-src can be used in any recent Linux distribution matching the CPU architecture.

To use xbps-src in your Linux distribution use the following instructions. Let’s start downloading the xbps static binaries:

If xbps-uunshare does not work because of lack of user_namespaces(7) support, try other chroot methods.

Clone the void-packages git repository:

and xbps-src should be fully functional; just start the bootstrap process, i.e:

The default masterdir is created in the current working directory, i.e void-packages/masterdir .

Remaking the masterdir

If for some reason you must update xbps-src and the bootstrap-update target is not enough, it’s possible to recreate a masterdir with two simple commands (please note that zap keeps your ccache/distcc/host directories intact):

Keeping your masterdir uptodate

Sometimes the bootstrap packages must be updated to the latest available version in repositories, this is accomplished with the bootstrap-update target:

Building 32bit packages on x86_64

Two ways are available to build 32bit packages on x86_64:

• cross compilation mode
• native mode with a 32bit masterdir

The first mode (cross compilation) is as easy as:

The second mode (native) needs a new x86 masterdir :

Building packages natively for the musl C library

Canonical way of building packages for same architecture but different C library is through dedicated masterdir. To build for x86_64-musl on glibc x86_64 system, prepare a new masterdir with the musl packages:

Your new masterdir is now ready to build packages natively for the musl C library:

Building void base-system from scratch

To rebuild all packages in base-system for your native architecture:

It’s also possible to cross compile everything from scratch:

Источник