Fix some incorrect article headers and (in theory) finished Hugo YAML adding. Moved a build bit to Building a Package.
This commit is contained in:
Joshua Strobl
parent
07417dc394
commit
0a1913ebea
|
|
@ -1,8 +1,11 @@
|
|||
## Building a Package
|
||||
---
|
||||
title: Building a Package
|
||||
---
|
||||
# Building a Package
|
||||
|
||||
This guide will walk you through setting up the file(s), tooling, and building your package.
|
||||
|
||||
### Setting up Packager file
|
||||
## Setting up Packager file
|
||||
|
||||
In order to utilise the build system, you must first set up a configuration file that has your packager details.
|
||||
|
||||
|
|
@ -14,11 +17,11 @@ Name=Your Name Here
|
|||
Email=your.email@address
|
||||
```
|
||||
|
||||
### Using solbuild
|
||||
## Using solbuild
|
||||
|
||||
The `solbuild` tool must first be initialized with a base image. All builds thereafter will use this as a base, and construct a temporary overlay root to save on time and disk space in builds.
|
||||
|
||||
#### Initializing solbuild
|
||||
### Initializing solbuild
|
||||
|
||||
First, install the system.devel component by calling: `sudo eopkg it -c system.devel`
|
||||
|
||||
|
|
@ -28,13 +31,13 @@ Next, you need to initialize solbuild via `sudo solbuild init`
|
|||
|
||||
This will take some time as it downloads and prepares the image. It is a good idea to update the root on a semi-regular basis, otherwise the updates will be applied on every build.
|
||||
|
||||
#### Updating solbuild
|
||||
### Updating solbuild
|
||||
|
||||
It is a good idea to keep the base image updated. It will help reduce build times by not having to repeatedly download updates to packages in the base image, and will strictly need to pull down the packages your build needs.
|
||||
|
||||
To update solbuild, run: `sudo solbuild update`
|
||||
|
||||
### Setting up common
|
||||
## Setting up common
|
||||
|
||||
Next you need to set up `common`, a set of make scripts that enables you to more easily manage, build, check, and publish packages.
|
||||
|
||||
|
|
@ -63,7 +66,7 @@ Your folder should look something similar to this:
|
|||
| Makefile.iso
|
||||
```
|
||||
|
||||
### Building packages (Solus only)
|
||||
## Building packages (Solus only)
|
||||
|
||||
After setting up common, you can now build the package. Note that build dependencies and such will be installed locally (in the chroot environment).
|
||||
|
||||
|
|
@ -73,4 +76,7 @@ make
|
|||
|
||||
You will be prompted to enter your password by sudo so dependencies may be downloaded and the necessary eopkg files may be generated.
|
||||
|
||||
You may find other `common` commands [here](https://git.solus-project.com/common/about/).
|
||||
You may find other `common` commands [here](https://git.solus-project.com/common/about/).
|
||||
|
||||
Once you’ve achieved a successful build, the resulting `.eopkg` files will be moved to the current directory, along with the machine file, `pspec_*.xml` (currently `pspec_x86_64.xml`). We recommending checking the contents of your
|
||||
generated eopkg file(s) to ensure everything is located in the appropriate locations. You can do this by using `lseopkg file_name.eopkg`.
|
||||
|
|
@ -1,7 +1,12 @@
|
|||
## Requesting A Package
|
||||
---
|
||||
title: Requesting a Package
|
||||
---
|
||||
# Requesting A Package
|
||||
|
||||
Packages are how users install Software in Solus, however if we are missing one you can let us know using our Bug Tracker. **Please look to see if a bug has been filed for the software or library you require**. If there isn't an existing request, you can
|
||||
use the template below for requesting packages to be added to the Solus Package Repository or Third Party Repository.
|
||||
Packages are how users install Software in Solus, however if we are missing one you can let us know using our Task Tracker.
|
||||
|
||||
**Please look to see if a bug has been filed for the software or library you require**. If there isn't an existing request, you can use the template below for requesting packages to be added to the Solus
|
||||
Package Repository or Third Party Repository.
|
||||
|
||||
Please provide as much of the following information as possible:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,25 +1,28 @@
|
|||
## Submitting the Package
|
||||
---
|
||||
title: Submitting the Package
|
||||
---
|
||||
# Submitting the Package
|
||||
|
||||
Once you’ve achieved a successful build, the resulting `.eopkg` files will be moved to the current directory, along with the machine file, `pspec_*.xml` (currently `pspec_x86_64.xml`). We recommending checking the contents of your
|
||||
generated eopkg file(s) to ensure everything is located in the appropriate locations. You can do this by using `lseopkg file_name.eopkg`.
|
||||
This article will walk you through submitting a patch for a package for review and inclusion in the Solus repository.
|
||||
|
||||
### Patches
|
||||
When sending patches to include your package in our repo, note that we do not accept binary files. We will need the `package.yml`, the `pspec_*.xml`, the `Makefile`, any ABI files generated, as well as the
|
||||
`files/` directory if applicable included within the patch. These patches are required to be [git format patches](https://git-scm.com/docs/git-format-patch) and submitted to the Patch Submissions Tag, in
|
||||
Maniphest, on our [Developer Portal](https://dev.solus-project.com).
|
||||
|
||||
When sending patches to include your package in our repo, note that we do not accept binary files. We will need the `package.yml`, the `pspec_*.xml`, the `Makefile`, any ABI files generated, as well as the `files/` directory if applicable included within
|
||||
the patch. These patches are required to be [git format patches](https://git-scm.com/docs/git-format-patch) and submitted to the Patch Submissions Tag, in Maniphest, on our [Developer Portal](https://dev.solus-project.com).
|
||||
|
||||
To generate a patch, first ensure your package directory is a git repo by running `git init`. Next, use `git add filename` to add files, where filename is, for example, the package.yml. Next, do `git commit` and write an appropriate commit message,
|
||||
such as "Initial commit of packagename".
|
||||
To generate a patch, first ensure your package directory is a git repo by running `git init`. Next, use `git add filename` to add files, where filename is, for example, the package.yml. Next, do `git commit` and
|
||||
write an appropriate commit message, such as "Initial commit of packagename".
|
||||
|
||||
Once a git commit is made, use `git format-patch -n1` to create a .patch file.
|
||||
|
||||
### Maintainership
|
||||
## Maintainership
|
||||
|
||||
Submission directly to a repository is only possible for maintainers. As a maintainer you may freely push to your package(s) and initiate builds for them, which will be pushed to the unstable repository. You can watch builds [here](https://build.solus-project.com/).
|
||||
Submission directly to a repository is only possible for maintainers. As a maintainer you may freely push to your package(s) and initiate builds for them, which will be pushed to the unstable repository. You can watch
|
||||
builds [here](https://build.solus-project.com/).
|
||||
|
||||
Pushing changes is not possible unless you have maintainer access. The same is also true of `make publish`.
|
||||
|
||||
To request maintainer rights for a repository, it is expected that some level of contribution/maintenance has already happened by way of testing/patching, and there is reasonable trust demonstrated to "hand the keys" over to a repository.
|
||||
To request maintainer rights for a repository, it is expected that some level of contribution/maintenance has already happened by way of testing/patching, and there is reasonable trust demonstrated to "hand the keys"
|
||||
over to a repository.
|
||||
|
||||
Currently, the request mechanism [contact Ikey on IRC](/articles/contributing/getting-involved/en). It is far easier to grant access to active community members than those unknown to the project.
|
||||
|
||||
|
|
|
|||
Reference in New Issue