From bfb4599a5c8912877e94f98ff64d85e58acc24e9 Mon Sep 17 00:00:00 2001 From: Joey Riches Date: Sun, 8 Sep 2024 01:26:19 +0100 Subject: [PATCH] man: Regen documentation --- man/package.yml.5 | 148 +++++++++++++++++------------------ man/package.yml.5.html | 15 +--- man/package.yml.5.md | 10 +-- man/ypkg-build.1 | 24 +++--- man/ypkg-build.1.html | 6 +- man/ypkg-install-deps.1 | 24 +++--- man/ypkg-install-deps.1.html | 6 +- man/ypkg.1 | 24 +++--- man/ypkg.1.html | 6 +- 9 files changed, 121 insertions(+), 142 deletions(-) diff --git a/man/package.yml.5 b/man/package.yml.5 index e4f51fa..b89ddb7 100644 --- a/man/package.yml.5 +++ b/man/package.yml.5 @@ -1,6 +1,6 @@ -.\" generated with Ronn-NG/v0.9.1 -.\" http://github.com/apjanke/ronn-ng/tree/0.9.1 -.TH "PACKAGE\.YML" "5" "October 2023" "" +.\" generated with Ronn-NG/v0.10.1 +.\" http://github.com/apjanke/ronn-ng/tree/0.10.1 +.TH "PACKAGE\.YML" "5" "September 2024" "" .SH "NAME" \fBpackage\.yml\fR \- Solus package build format .SH "SYNOPSIS" @@ -17,14 +17,14 @@ The primary format of package builds in Solus, \fBpackage\.yml(5)\fR provides a \fBTypes\fR .P Some of the specialised types expected by \fBpackage\.yml(5)\fR are explained below\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBdict(s)\fR .IP This is a set of one or more \fBkey\fR:\fBvalue\fR mappings\. These are always in a list format\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBmultimap\fR .IP -This is a \fBkey\fR:\fBvalue\fR mapping where the \fBkey\fR is IMPLICIT\. That is to say, it is acceptable to omit the key\. A single value passed as the \fBvalue\fR will set the implicit key\'s component\. +This is a \fBkey\fR:\fBvalue\fR mapping where the \fBkey\fR is IMPLICIT\. That is to say, it is acceptable to omit the key\. A single value passed as the \fBvalue\fR will set the implicit key's component\. .IP In all instances the implicit key is the \fBmain package\fR\. The \fBmultimap\fR format can accept a list instead of a string as a value, and each item in that list also follows the implicit key policy\. .IP @@ -32,27 +32,27 @@ For each item in the list, if the \fBkey\fR is EXPLICIT, by using \fBdict\fR sty .IP Within \fBypkg(1)\fR, that key is always a package name\. This name should be the shortform name, not the fully qualified name, i\.e the subpackage name without the \fBname\fR prefix\. .IP -As a special exception to the subpackage rule, keys beginning with \fB^\fR will result in an explicitly named package lookup, i\.e\. one that doesn\'t follow the subpackage convention\. This should be used only in rare cases where it is illogical to share a common root name, or a migration with name changes from a legacy format is too complex\. +As a special exception to the subpackage rule, keys beginning with \fB^\fR will result in an explicitly named package lookup, i\.e\. one that doesn't follow the subpackage convention\. This should be used only in rare cases where it is illogical to share a common root name, or a migration with name changes from a legacy format is too complex\. .IP This allows a general key to accept sane defaults, but also allows the key to be extended to override attributes of a subpackage\. .IP "" 0 .P \fBMandatory Keys\fR -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBname\fR [string] .IP Set the name of the package\. In general this should try to match the upstream source name wherever possible\. All subpackages generated by \fBypkg\-build(1)\fR will have this \fBname\fR as a prefix\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBversion\fR [string] .IP The version of the software being packaged\. This should match the upstream version, i\.e\. that of the tarball or git tag\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBrelease\fR [integer] .IP Packages within Solus are updated by their \fBrelease number\fR\. This number must start at 1 in new packages, and be incremented for every new update or change to the package that is published\. .IP It is perfectly acceptable to push an update with a \fBlower version\fR by bumping the release number\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBlicense\fR [string(s)] .IP One or more strings that identify the software license of this package\. This should in most cases be a recognised \fBSPDX\fR license name\. @@ -62,7 +62,7 @@ One or more strings that identify the software license of this package\. This sh .fi .IP "" 0 -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBsource\fR [dict(s)] .IP This key expects a list of \fBkey\fR:\fBvalue\fR mappings, to declare the sources that this package will use\. A "simple source" could be a tarball, where the key is the upstream URL, and the value must be a valid \fBsha256sum(1)\fR for that tarball\. @@ -70,26 +70,26 @@ This key expects a list of \fBkey\fR:\fBvalue\fR mappings, to declare the source You can list multiple sources and they will all be fetched for the build process, but only the first will be extracted\. You can locate these other sources during your build with the \fB$sources\fR variable\. .IP \fBgit(1)\fR sources are also supported, and can be identified by prefixing the URI with \fBgit|\fR\. The expected value should be a commit, sha reference, or a tag\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBcomponent\fR [multimap] .IP This key sets the package component, that is to say, the logical unit of organisation that it belongs to\. Check \fBeopkg lc\fR for existing component names\. .IP \fBcomponent\fR is a multimap key, therefore if passed a single string value it will set the component for the main package\. However, you may instead pass a list of the subpackage names, and set their component individually using the map \fBvalue\fR\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBsummary\fR [multimap] .IP Set the "short" description of a package, i\.e\. a one line explanation of what an item is\. Use the subpackage names in the explicit key for this multimap to override subpackage summaries\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBdescription\fR [multimap] .IP -Set the full description of a package, i\.e\. a more in depth explanation of the software/package\'s functionality\. This is the large description that will be displayed in \fBeopkg\fR and the \fBsolus\-sc\fR\. Use the subpackage names in the explicit key for this multimap to override subpackage descriptions\. +Set the full description of a package, i\.e\. a more in depth explanation of the software/package's functionality\. This is the large description that will be displayed in \fBeopkg\fR and the \fBsolus\-sc\fR\. Use the subpackage names in the explicit key for this multimap to override subpackage descriptions\. .IP "" 0 .P \fBOptional Keys\fR .P These keys are not mandatory to a \fBpackage\.yml\fR file, but may be used to configure additional functionality\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBbuilddeps\fR [list] .IP Specifies the build dependencies required to actually make this package build in an isolated environment (\fBsolbuild(1)\fR)\. @@ -99,7 +99,7 @@ You may use full package names here, though it is preferable to use the \fBpkg\- \fBypkg\-build(1)\fR understands pkgconfig dependencies denoted inside either the \fBpkgconfig($name)\fR identifier, or \fBpkgconfig32($name)\fR for emul32 build dependencies\. .IP It is not required to list any package here that exists in the \fBsystem\.base\fR or \fBsystem\.devel\fR component\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBcheckdeps\fR [list] .IP Specifies the build and/or run dependencies required to build and/or run the tests of this package in an isolated environment (\fBsolbuild(1)\fR)\. @@ -109,41 +109,41 @@ You may use full package names here, though it is preferable to use the \fBpkg\- \fBypkg\-build(1)\fR understands pkgconfig dependencies denoted inside either the \fBpkgconfig($name)\fR identifier, or \fBpkgconfig32($name)\fR for emul32 build dependencies\. .IP It is not required to list any package here that exists in the \fBsystem\.base\fR or \fBsystem\.devel\fR component\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBclang\fR [boolean] .IP Set this key to \fByes\fR to force building this package with the \fBclang\fR compiler\. The build environment will be configured to use \fBclang\fR as the \fB$CC\fR and \fBclang++\fR as the \fB$CXX\fR variables\. .IP By default this key is set to \fBno\fR\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBccache\fR [boolean] .IP If configured correctly, \fBypkg\-build(1)\fR will automatically use \fBccache(1)\fR\. When using \fBsolbuild(1)\fR this is almost always the case\. However, there may be some cases when ccache can break the build, or is ill advised\. .IP Whilst the default value of this key is \fByes\fR, you can force disable the use of ccache by setting it to \fBno\fR\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBdevel\fR [boolean] .IP Force all built packages to belong to the \fBsystem\.devel\fR component\. This will become deprecated in future, and currently defaults to \fBno\fR\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBextract\fR [boolean] .IP By default, \fBypkg\-build(1)\fR will extract all sources listed in the file\. If this is undesirable, set this key to \fBno\fR to disable this automatic extraction\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBautodep\fR [boolean] .IP -After a build has finished, \fBypkg\-build(1)\fR will automatically scan the package files to determine dependencies between the package and any of it\'s subpackages, and to external packages in the build environment\. +After a build has finished, \fBypkg\-build(1)\fR will automatically scan the package files to determine dependencies between the package and any of it's subpackages, and to external packages in the build environment\. .IP This is essential in most cases, as it allows packages to benefit from automatic dependencies and ensures the user always gets all of the packages needed to run this software when installing it\. .IP If for any reason you need to disable this functionality, i\.e\. for bootstrapping or sideloading, set this key to \fBno\fR\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBemul32\fR [boolean] .IP \fBypkg\-build(1)\fR can optionally build your package in a multilib configuration\. If this key is set to \fByes\fR, the buildset will double, and the first build configuration will be set up for a \fB32\-bit\fR ("emul32") build\. ypkg will automatically split off \fB\-32bit\fR and \fB\-32bit\-devel\fR subpackages in this instance, using the \fB/usr/lib32\fR library directory\. It will also add additional build dependencies automatically for 32\-bit builds\. .IP By default, this key is set to \fBno\fR\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBlibsplit\fR [boolean] .IP The default patterns include logic to split subpackages according to the library files in library directory\. It is standard practice for ypkg to split \fB*\.so\fR symlinks into the automatic \fBdevel\fR subpackage, along with other development assets such as \fBpkgconfig\fR and \fB*\.h\fR files\. @@ -151,19 +151,19 @@ The default patterns include logic to split subpackages according to the library Some software packages provide \fB*\.so\fR files in the libdir that are not symlinks, or are required for "main" operation\. In this instance you can set this key to \fBno\fR to disable this pattern\. .IP By default, this key is set to \fByes\fR, and should only be disabled if truly required\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBrundeps\fR [multimap] .IP Provide a list of additional runtime dependencies for the main package\. These names should be fully qualified package names in the list, even for subpackages\. .IP If the EXPLICIT multimap key is set, then the runtime dependencies will be added to the subpackage instead\. Note that you can pass a list or a single string value to the EXPLICIT rundep\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBreplaces\fR [multimap] .IP When exported in the package index, this will indicate to the package manager that THIS package now replaces the name in the value\. .IP You may also set \fBreplaces\fR on subpackages using the multimap notation\. Only one value per subpackage is allowed\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBpatterns\fR [multimap] .IP Control package splitting and dynamically generate subpackages\. The EXPLICIT key is used to specify the new (or existing!) subpackage name\. The "pattern" is a shell compatible \fBglob(3)\fR expression\. @@ -171,7 +171,7 @@ Control package splitting and dynamically generate subpackages\. The EXPLICIT ke All files captured by this expression will then end up in that subpackage\. Each successive pattern takes priority over the one listed before it, so if your first pattern unavoidably captures files you need in ANOTHER subpackage, simply list that pattern later\. .IP \fBypkg\-build(1)\fR ensures that a file cannot belong to multiple packages, and that the last specified pattern, if matching, ALWAYS wins\. It is even possible to suppress generation of the main package, by pattern globbing \fB/*\fR to a subpackage\. This will not cause any breakage\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBpermanent\fR [list] .IP A list of patterns used to mark files as permanent\. Any file within the resulting binary packages that matches the path pattern, is marked as a permanent file\. @@ -179,7 +179,7 @@ A list of patterns used to mark files as permanent\. Any file within the resulti These files will not be removed from the filesystem when upgrading or reinstalling the package\. They will persist during standard upgrade operations\. .IP This should only be used in critical chain packages such as the kernel or drivers, where the domain of control is outside of the package manager, and the package is simply used as an update delivery mechanism\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBstrip\fR [boolean] .IP By default, this key is enabled, and as a result \fBypkg\-build(1)\fR will automatically strip files after the build has done, including \fBELF\fR libraries & binaries\. @@ -187,27 +187,23 @@ By default, this key is enabled, and as a result \fBypkg\-build(1)\fR will autom In most cases, stripping should remain enabled\. However, there are known cases when stripping should be avoided, such as when complying with a distribution policy of binary only software, or when dealing with files that only appear to be standard ELF files\. .IP The Go programming language generates \fB*\.a\fR archive files that under no circumstance should be stripped, and there are likely other cases\. This key, when set to \fBno\fR, will disable any and all stripping\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBlastrip\fR [boolean] .IP -By default, this key is enabled, and will result in \fB*\.la\fR libtool files being stripped from the build\. However in some very rare cases these files need to be preserved because they\'re not \fBtrue\fR libtool scripts which led to the creation of successful \fB\.so\fR linkage\. +By default, this key is enabled, and will result in \fB*\.la\fR libtool files being stripped from the build\. However in some very rare cases these files need to be preserved because they're not \fBtrue\fR libtool scripts which led to the creation of successful \fB\.so\fR linkage\. .IP If in doubt, omit this option where possible\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBmancompress\fR [boolean] .IP By default, this key is disabled\. Enables compression of man/info pages using gzip at the maximum compression level, to decrease the installed size of the package on disk\. Disabled by default as it generally increases the size of eopkg file(s) due to xz having a hard time compressing pre\-compressed gzip files\. Only enable when it significantly reduces the installed size of a package on disk without sacrificing eopkg size too much\. -.IP "\[ci]" 4 -\fBfatfakeroot\fR [boolean] -.IP -By default, this key is disabled\. By default, fakeroot is only enabled for the "install" and "check" steps due to it\'s massive performance overhead\. Enabling, this key will enable fakeroot for all build stages\. You may want to enable this if you are experiencing strange "Permission Denied" errors in the "build" stage, or when rebuilding a reverse dependency against a package\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBdebug\fR [boolean] .IP By default, this key is enabled, and as a result \fBypkg\-build(1)\fR will automatically create resulting \fB\-dbginfo\fR packages where it can\. .IP In the majority of cases, this is the desired behaviour in full build environments, such as a build server\. However in very rare cases, this may cause problems for the package, especially if it contains binaries that have not been bootstrapped with the native toolchain\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBavx2\fR [boolean] .IP If set, the package will be rebuilt again with the \fBx86\-64\-v3\fR microarchitecture to enable libraries to be optimised to use newer hardware instructions such as \fBAdvanced Vector Extensions\fR\. From baseline (\fBx86\-64\fR) to v3 (\fBx86\-64\-v3\fR) it allows the compiler to use additional instructions such as, but not limited to; SSE4\.2, SSSE3, POPCNT, CMPXCHG16B, MOVBE and AVX2\. @@ -215,45 +211,45 @@ If set, the package will be rebuilt again with the \fBx86\-64\-v3\fR microarchit The build will be configured to make use of the Glibc HWCaps (hardware capabilities) feature, by placing the libraries into the library directory suffix of \fBglibc\-hwcaps/x86\-64\-v3\fR i\.e\. \fB/usr/lib64/glibc\-hwcaps/x86\-64\-v3\fR\. .IP These libraries will be automatically loaded on the Solus installation if the hardware supports the \fBx86\-64\-v3\fR microarchitecture\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBoptimize\fR [list] .IP Valid keys are restricted to: -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBspeed\fR: Optimise this package for speed performance -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBsize\fR: Optimize the package build solely for size\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBno\-bind\-now\fR: Configure the package to disable certain flags, where RELRO is unsupported\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBno\-frame\-pointer\fR: Disable \fB\-fno\-omit\-frame\-pointer\fR and \fB\-mno\-omit\-leaf\-frame\-pointer\fR compiler flags -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBno\-symbolic\fR: Disable \fB\-Wl,\-Bsymbolic\-functions\fR linker flag -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBunroll\-loops\fR: Enable \fB\-funroll\-loops\fR\. Use this sparingly, only when it provides benefit\. -.IP "\[ci]" 4 -\fBrunpath\fR: Enable \fB\-Wl,\-\-enable\-new\-dtags\fR to make linker use RUNPATH\'s instead of RPATH\'s\. -.IP "\[ci]" 4 +.IP "\(bu" 4 +\fBrunpath\fR: Enable \fB\-Wl,\-\-enable\-new\-dtags\fR to make linker use RUNPATH's instead of RPATH's\. +.IP "\(bu" 4 \fBavx256\fR: Disables \fB\-mprefer\-vector\-width=128\fR in avx2 builds -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBthin\-lto\fR: Enable Thin Link Time Optimization -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBlto\fR: Enable Link Time Optimization -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBicf\-safe\fR: Enable \fB\-Wl,\-\-icf=safe\fR to utilize the safe Identical Code Folding linker optimization\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBicf\-all\fR: Enable \fB\-Wl,\-\-icf=all\fR to utilize the Identical Code Folding linker optimization\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBfunction\-sections\fR: Enables \fB\-ffunction\-sections\fR to generate a seperate ELF section for each function\. Recommended for icf with gcc\. .IP "" 0 -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBnetworking\fR [boolean] .IP When built using \fBsolbuild(1)\fR, access to the network is removed\. A new loopback device will be provided within the container\. This ensures that packages do not accidently download unverifiable content during build\. .IP If for any reason, networking is still required, you can set this key to \fByes\fR\. However, always evaluate whether it is avoidable first\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBenvironment\fR [unicode] .IP By default, this key is empty and no additional content is exported to each build step\. The \fBenvironment\fR key provides an easy method to export content such as variables to the environment for the entirety of the build (where the environment is reset between each build step)\. @@ -262,25 +258,25 @@ By default, this key is empty and no additional content is exported to each buil \fBBuild Steps\fR .P The build steps are text\-only data values\. \fBypkg\-build(1)\fR will interpret special "macro" values in these steps, and evaluate them in a new environment via the \fBbash(1)\fR shell\. -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBsetup\fR .IP Performed immediately after source preparation and extraction\. This is where you should look to patch your package if necessary, and perform any configuration routines (i\.e\. \fB%configure\fR) -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBbuild\fR .IP The main build step\. This is where you compile code and do long running code\. An example would be running \fB%make\fR -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBinstall\fR .IP The install step will install of the built files into the final installation directory, to be converted into a native \fB\.eopkg\fR file\. This is where your \fB%make_install\fR would happen, for example\. .IP -Remember, this is to install inside the \fBpackage\fR\. This doesn\'t impact the package installation on another users computer\. There is no "postinstall" concept currently supported by ypkg\. -.IP "\[ci]" 4 +Remember, this is to install inside the \fBpackage\fR\. This doesn't impact the package installation on another users computer\. There is no "postinstall" concept currently supported by ypkg\. +.IP "\(bu" 4 \fBcheck\fR .IP Run any test suites in this step\. This is the final step in the chain, and allows you to verify what you just built\. This is a good place to run \fB%make check\fR -.IP "\[ci]" 4 +.IP "\(bu" 4 \fBprofile\fR .IP If this step is present, then each build set that is enabled (native, \fBemul32\fR), will gain a series of new steps\. The build will be configured for profile guided optimisation, and this step will be used to execute the PGO workload\. @@ -300,7 +296,7 @@ In essence the workflow looks like this: .IP "" 0 .IP The compiler flags will be modifed automatically during each step to make PGO integration seamless\. For an real world case on how this helps, check out: -.IP "\[ci]" 4 +.IP "\(bu" 4 https://clearlinux\.org/blogs/profile\-guided\-optimization\-mariadb\-benchmarks .IP "" 0 @@ -309,14 +305,14 @@ https://clearlinux\.org/blogs/profile\-guided\-optimization\-mariadb\-benchmarks \fBMacros\fR .P ypkg supports a wide range of macros for easier package building\. They evolve often and quickly, so you should always refer to the main \fBpackage\.yml\fR documentation: -.IP "\[ci]" 4 +.IP "\(bu" 4 https://getsol\.us/articles/packaging/package\.yml/en/#actionable\-macros -.IP "\[ci]" 4 +.IP "\(bu" 4 https://getsol\.us/articles/packaging/package\.yml/en/#variable\-macros .IP "" 0 .P It may also be beneficial to study the \fBrc\.yml\fR file defining the build macros: -.IP "\[ci]" 4 +.IP "\(bu" 4 https://github\.com/getsolus/ypkg/blob/master/ypkg2/rc\.yml .IP "" 0 .SH "EXAMPLES" @@ -375,7 +371,7 @@ rundeps: \- somepkg \- devel: somepkg2 -# Rundeps, list as explicit key\'s value +# Rundeps, list as explicit key's value rundeps: \- somepkg \- devel: @@ -395,29 +391,29 @@ builddeps: .fi .IP "" 0 .SH "COPYRIGHT" -.IP "\[ci]" 4 +.IP "\(bu" 4 Copyright \(co 2016\-2020 Solus Project .IP "" 0 .P Released under the terms of the CC\-BY\-SA\-3\.0 license .SH "SEE ALSO" \fBsolbuild(1)\fR, \fBypkg(1)\fR \fBypkg\-build(1)\fR, \fBypkg\-install\-deps(1)\fR -.IP "\[ci]" 4 +.IP "\(bu" 4 https://getsol\.us/articles/packaging/package\.yml/en/ -.IP "\[ci]" 4 +.IP "\(bu" 4 https://github\.com/getsolus/ypkg -.IP "\[ci]" 4 +.IP "\(bu" 4 https://getsol\.us/articles/packaging -.IP "\[ci]" 4 +.IP "\(bu" 4 https://spdx\.org/licenses/ -.IP "\[ci]" 4 +.IP "\(bu" 4 https://en\.wikipedia\.org/wiki/Advanced_Vector_Extensions -.IP "\[ci]" 4 +.IP "\(bu" 4 https://en\.wikipedia\.org/wiki/Profile\-guided_optimization .IP "" 0 .SH "NOTES" Creative Commons Attribution\-ShareAlike 3\.0 Unported -.IP "\[ci]" 4 +.IP "\(bu" 4 http://creativecommons\.org/licenses/by\-sa/3\.0/ .IP "" 0 diff --git a/man/package.yml.5.html b/man/package.yml.5.html index 3f1ca23..8421897 100644 --- a/man/package.yml.5.html +++ b/man/package.yml.5.html @@ -1,8 +1,8 @@ - - + + package.yml(5) - Solus package build format