Added metadata
This commit is contained in:
Peter Boy
parent
11cdc574d7
commit
7786d90c72
5 changed files with 74 additions and 42 deletions
|
|
@ -53,7 +53,7 @@
|
|||
** xref:create-gpg-keys.adoc[Creating GPG Keys]
|
||||
** xref:grub2-bootloader.adoc[The GRUB2 Bootloader]
|
||||
** xref:root-account-locked.adoc[Root Account Locked]
|
||||
** xref:proc_setting-key-shortcut.adoc[Setting a key shortcut to run an application in GNOME]
|
||||
** xref:gnome-setting-key-shortcut.adoc[Setting a key shortcut to run an application in GNOME]
|
||||
** xref:disabling-automatic-screenlock.adoc[Disabling the GNOME automatic screen locking]
|
||||
** xref:viewing-logs.adoc[Viewing logs in Fedora]
|
||||
** xref:encrypting-drives-using-LUKS.adoc[Encrypting drives using LUKS]
|
||||
|
|
|
|||
|
|
@ -1,6 +1,3 @@
|
|||
ifdef::context[:parent-context: {context}]
|
||||
:context: setting-key-shortcut
|
||||
[id='setting-key-shortcut_{context}']
|
||||
= Setting a key shortcut to run an application in GNOME
|
||||
Adam Samalik; Anthony McGlone
|
||||
:page-authors: {author},{author_2}
|
||||
|
|
@ -9,6 +6,7 @@ Adam Samalik; Anthony McGlone
|
|||
:revremark: update procedure
|
||||
:category: how-to
|
||||
:tags: gnome, workstation, shortcut
|
||||
:page-aliases: proc_setting-key-shortcut
|
||||
|
||||
If you frequently use a certain application, you can set a keyboard shortcut to quickly launch that application on GNOME.
|
||||
|
||||
|
|
@ -43,5 +41,4 @@ To remove a shortcut:
|
|||
. Click on the shortcut that you wish to remove.
|
||||
. Click the *Remove* button.
|
||||
|
||||
ifdef::parent-context[:context: {parent-context}]
|
||||
ifndef::parent-context[:!context:]
|
||||
|
||||
|
|
@ -1,4 +1,11 @@
|
|||
= PackageKit Items Not Found
|
||||
Caleb McKee; Frank Sträter
|
||||
:revnumber: unknown
|
||||
:revdate: 2021-02-10
|
||||
:category: Administration
|
||||
:tags: How-to troubleshooting
|
||||
//:page-aliases:
|
||||
|
||||
|
||||
[[missing-package]]
|
||||
== Missing Package
|
||||
|
|
|
|||
|
|
@ -1,8 +1,14 @@
|
|||
include::{partialsdir}/attributes.adoc[]
|
||||
|
||||
= How to Publish your Software on Copr, Fedora's User Repository
|
||||
:toc:
|
||||
Christopher Engelhard; Jean-Baptiste Holcroft; Otto Urpelainen
|
||||
:revnumber: unspecified
|
||||
:revdate: 2022-02-05
|
||||
:category: Development
|
||||
:tags: Tutorial Copr
|
||||
// :page-aliases:
|
||||
|
||||
[abstract]
|
||||
This is a short tutorial on how to create and maintain a Copr repository for your software in an automated fashion. It assumes some basic familiarity with Git & how to create a RPM package.
|
||||
|
||||
In this guide, we'll
|
||||
|
|
@ -22,23 +28,22 @@ TIP: You can set up similar automation when packaging someone else's program, i.
|
|||
== Prerequisites
|
||||
The following is needed:
|
||||
|
||||
. Our program's source in a publicly available git repository somewhere. This tutorial uses a simple example program - hellocopr - to demonstrate the process.
|
||||
The program and all files referenced in this guide can be found in the link:https://pagure.io/copr-tito-quickdoc[project's git repository]. It's a very simple (& pointless) python program with a setuptools installer:
|
||||
. Our program's source in a _publicly available git repository_ somewhere. This tutorial uses a simple example program - hellocopr - to demonstrate the process. The program and all files referenced in this guide can be found in the link:https://pagure.io/copr-tito-quickdoc[project's git repository]. It's a very simple (& pointless) python program with a setuptools installer:
|
||||
+
|
||||
```
|
||||
[source,]
|
||||
----
|
||||
user@host ~/copr-tito-quickdoc % ls
|
||||
doc LICENSE README.md requirements.txt setup.py src
|
||||
|
||||
user@host ~/copr-tito-quickdoc % ls src/hellocopr
|
||||
colors.py hellocopr.py __init__.py
|
||||
```
|
||||
+
|
||||
. A Fedora (FAS) account in order to be able to create repositories on Copr. This tutorial's demo repository can be found link:https://copr.fedorainfracloud.org/coprs/lcts/hellocopr/[here].
|
||||
----
|
||||
|
||||
. `tito` installed on your system. link:https://github.com/rpm-software-management/tito[Tito] is capable of a lot of advanced automation for package creation, most of which we won't need here. Check out its documentation to learn more.
|
||||
. A _Fedora (FAS) account_ in order to be able to create repositories on Copr. This tutorial's demo repository can be found link:https://copr.fedorainfracloud.org/coprs/lcts/hellocopr/[here].
|
||||
|
||||
. A specfile for our program.
|
||||
For more information on how to create one,
|
||||
. The utility _`tito`_ installed on your system. link:https://github.com/rpm-software-management/tito[Tito] is capable of a lot of advanced automation for package creation, most of which we won't need here. Check out its documentation to learn more.
|
||||
|
||||
. A _specfile_ for our program. For more information on how to create one,
|
||||
refer to xref:package-maintainers::Packaging_Tutorial_GNU_Hello.adoc[Packaging Tutorial: GNU Hello]
|
||||
or adapt this tutorial's link:https://pagure.io/copr-tito-quickdoc/blob/master/f/doc/hellocopr.spec.annotated[annotated example specfile].
|
||||
|
||||
|
|
@ -50,7 +55,7 @@ Copy link:https://pagure.io/copr-tito-quickdoc/c/00963ac9339a13eefd2ab1ca42b1f72
|
|||
|
||||
. The values of `Version:` and `Release:` do not matter, since these will be managed by tito. It makes sense to set them to `Version: 0.0.0` and `Release: 0%\{?dist}` to mark that this package hasn't been built yet.
|
||||
|
||||
. tito will also handle the creation of the source tarball from the git repository, so change the `Source0:` URL to the filename `%\{name}-%\{version}.tar.gz` & add a comment to tell users how to get the tarball
|
||||
. tito will also handle the creation of the source tarball from the git repository, so change the _`Source0:` URL_ to the filename `%\{name}-%\{version}.tar.gz` & add a comment to tell users how to get the tarball
|
||||
|
||||
. The changelog can be left empty.
|
||||
+
|
||||
|
|
@ -86,9 +91,10 @@ Done!
|
|||
|
||||
This creates link:https://pagure.io/copr-tito-quickdoc/c/7a6919d3dd56943bb988a755f8233157965aa9bb?branch=master[a subdirectory `.tito` with some default configuration], which can be left unchanged for now.
|
||||
|
||||
We can now do a test build of the package using `tito build`. Usually, tito will build from a tag, which we haven't created yet. However, using the `--test` flag, we can build from the most recent commit instead, which will be written to `/tmp/tito`:
|
||||
We can now do a test build of the package using _`tito build`_. Usually, tito will build from a tag, which we haven't created yet. However, using the `--test` flag, we can build from the most recent commit instead, which will be written to `/tmp/tito`:
|
||||
|
||||
```
|
||||
[source,]
|
||||
----
|
||||
user@host ~/copr-tito-quickdoc % tito build --rpm --test
|
||||
Creating output directory: /tmp/tito
|
||||
WARNING: unable to lookup latest package tag, building untagged test project
|
||||
|
|
@ -99,13 +105,14 @@ Wrote: /tmp/tito/hellocopr-git-11.7a6919d.tar.gz
|
|||
|
||||
Successfully built: /tmp/tito/hellocopr-0.0.0-0.git.11.7a6919d.fc32.src.rpm
|
||||
- /tmp/tito/noarch/hellocopr-0.0.0-0.git.11.7a6919d.fc32.noarch.rpm
|
||||
```
|
||||
----
|
||||
|
||||
Once we've fixed any issues with the package that might crop up, we can let tito create a package release using `tito tag`. Since we haven't set a proper version yet, we need to pass it to tito for the first tag:
|
||||
Once we've fixed any issues with the package that might crop up, we can let _tito_ create a package release using `tito tag`. Since we haven't set a proper version yet, we need to pass it to tito for the first tag:
|
||||
|
||||
```
|
||||
[source,]
|
||||
----
|
||||
user@host ~/copr-tito-quickdoc % tito tag --use-version 1.0.0
|
||||
```
|
||||
----
|
||||
|
||||
This will open the editor & display a pre-formatted changelog entry build up from all commits since the last release, which we can edit as needed. Since there have been none so far, the entry will just contain "- new package built with tito". Save the file, link:https://pagure.io/copr-tito-quickdoc/c/f44e81d695df669bcdb7237612baf41b80da98e0?branch=master[and tito will]
|
||||
|
||||
|
|
@ -117,7 +124,8 @@ This will open the editor & display a pre-formatted changelog entry build up fro
|
|||
|
||||
. commit the result and tag it with `<name>-<version>-<release>`, i.e. `hellocopr-1.0.0-1`
|
||||
+
|
||||
```
|
||||
[source,]
|
||||
----
|
||||
user@host ~/copr-tito-quickdoc % tito tag --use-version 1.0.0
|
||||
Creating output directory: /tmp/tito
|
||||
Tagging new version of hellocopr: untagged -> 1.0.0-1
|
||||
|
|
@ -125,10 +133,11 @@ Created tag: hellocopr-1.0.0-1
|
|||
View: git show HEAD
|
||||
Undo: tito tag -u
|
||||
Push: git push --follow-tags origin
|
||||
```
|
||||
----
|
||||
|
||||
Push to the commits & tags to the remote using `git push --follow-tags`, and we're ready to release the package on Copr.
|
||||
|
||||
|
||||
== Step 2: Publishing the package in a Copr repository
|
||||
|
||||
. Go to https://copr.fedorainfracloud.org/ and log in. Once done, click on _New Project_ to start creating a repository for our program. On the following input mask,
|
||||
|
|
@ -150,11 +159,12 @@ Push to the commits & tags to the remote using `git push --follow-tags`, and we'
|
|||
. Your package will appear in the list of packages. Hit _Rebuild_ to trigger a build. The following page lets you change any build options if necessary, we'll just use the defaults, i.e. the options we set in the previous step. Hit _Submit_ and Copr will build the package from the tito tag we created in Step 1.
|
||||
|
||||
Once the build has finished, you can test installing the package from Copr by activating your repository.
|
||||
```
|
||||
[source,]
|
||||
----
|
||||
user@host ~/copr-tito-quickdoc % sudo dnf copr enable <username>/hellocopr
|
||||
|
||||
user@host ~/copr-tito-quickdoc % sudo dnf install hellocopr
|
||||
```
|
||||
----
|
||||
|
||||
== Step 3: Automate package (re)-builds
|
||||
|
||||
|
|
@ -169,7 +179,9 @@ Now, to test this, let's make some changes to our program that will come in hand
|
|||
Currently, the example program has its version hardcoded at multiple places. link:https://pagure.io/copr-tito-quickdoc/c/61abf1cdf622d8c9fb4f03eb6b06c4ddc1677362?branch=master[Let's change this] so that the version string is sourced from a single file. Which file this is doesn't matter, but ideally the version variable should be the only thing in it that is likely to change. In this case, we use the previously empty `src/hellocopr/pass:[__]initpass:[__].py`. We name this new version '1.0.1'.
|
||||
|
||||
Commit the changes, and create a new release with tito
|
||||
```
|
||||
|
||||
[source,]
|
||||
----
|
||||
user@host ~/copr-tito-quickdoc % tito tag
|
||||
Creating output directory: /tmp/tito
|
||||
Tagging new version of hellocopr: 1.0.0-1 -> 1.0.1-1
|
||||
|
|
@ -177,7 +189,8 @@ Created tag: hellocopr-1.0.1-1
|
|||
View: git show HEAD
|
||||
Undo: tito tag -u
|
||||
Push: git push --follow-tags origin
|
||||
```
|
||||
----
|
||||
|
||||
Note that by ommiting the `--use-version` option, tito now updates the version automatically. It does so by
|
||||
|
||||
. Increasing the Version's final digit by 1 - `1.0.0` -> `1.0.1`
|
||||
|
|
@ -192,24 +205,28 @@ Push the resulting commit & tag, and if you now check your projects page on Copr
|
|||
If you check the git log, you'll find that I actually forgot to update hellocopr's version variable to 1.0.1. We don't want that to happen again. Luckily, since we single-source our version, we can let tito automatically generate this file from a template.
|
||||
|
||||
First, copy the version source file `src/hellocopr/pass:[__]initpass:[__].py` to `.tito/templates/pass:[__]initpass:[__].py.template`. Then, open the template file and replace the version string with `$version`. It also makes sense to add a note that the file is managed by tito and should not be edited manually.
|
||||
```
|
||||
[source,]
|
||||
----
|
||||
user@host ~/copr-tito-quickdoc % cat .tito/templates/__init__.py.template
|
||||
...
|
||||
# This file is automatically created from a template by tito. Do not edit it manually.
|
||||
|
||||
__version__ = '$version'
|
||||
```
|
||||
----
|
||||
|
||||
Next, add the following to `.tito/tito.props`
|
||||
```
|
||||
[source,]
|
||||
----
|
||||
[version_template]
|
||||
destination_file = src/hellocopr/__init__.py
|
||||
template_file = .tito/templates/__init__.py.template
|
||||
```
|
||||
----
|
||||
|
||||
https://pagure.io/copr-tito-quickdoc/c/28600f6e41d5a4b60f2e47cf077f2fe2d9224e1d?branch=master[Commit the changes]. Now, when we tag a new release, tito will take the template, replace `$version` with whatever version was tagged, and copy the resulting file to `src/hellocopr/pass:[__]initpass:[__].py` before updating the spec file and commiting the changes.
|
||||
|
||||
We can test this by tagging a new release:
|
||||
```
|
||||
[source,]
|
||||
----
|
||||
user@host ~/copr-tito-quickdoc % % tito tag
|
||||
Creating output directory: /tmp/tito
|
||||
Tagging new version of hellocopr: 1.0.1-1 -> 1.0.2-1
|
||||
|
|
@ -223,7 +240,8 @@ user@host ~/copr-tito-quickdoc % cat src/hellocopr/__init__.py
|
|||
# This file is automatically created from a template by tito. Do not edit it manually.
|
||||
|
||||
__version__ = '1.0.2'
|
||||
```
|
||||
----
|
||||
|
||||
If you again push the tag to the remote repo, Copr will again automatically trigger a rebuild.
|
||||
|
||||
== Release procedure in brief
|
||||
|
|
@ -247,12 +265,13 @@ To do so, the following changes need to be made to the procedure described above
|
|||
. Also in the spec file, set the `Version:` back to whatever version the program is at and `Source0:` back to the tarball URL. You can use macros like `%\{version}` for the latter to automatically follow version changes.
|
||||
. Modify tito's `.tito/tito.props` to, one, not try to build a source tarball and two, bump the `Release:` instead of the `Version:` when tagging
|
||||
+
|
||||
```
|
||||
[source,]
|
||||
----
|
||||
[buildconfig]
|
||||
builder = tito.builder.NoTgzBuilder
|
||||
tagger = tito.tagger.ReleaseTagger
|
||||
```
|
||||
+
|
||||
----
|
||||
|
||||
. Don't do any tito templating
|
||||
|
||||
The rest of the procedure stays the same. If you make changes to the package without changing the source, you can just tag a new release with tito. If you do update the source tarball, you need to update the `Version:` field and reset `Release:` to `0%\{?dist}` before tagging.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,16 @@
|
|||
= How to use QEMU
|
||||
Richard Gregory
|
||||
:revnumber: unspecified
|
||||
:revdate: 2020-11-05
|
||||
:category: Virtualisation
|
||||
:tags: How-to Qemu
|
||||
// :page-aliases:
|
||||
|
||||
|
||||
|
||||
[abstract]
|
||||
QEMU is a very flexible virtualization technology however it is quite slow and it is recommended that you understand and evaluate alternative solutions before picking this one.
|
||||
Refer to https://fedoraproject.org/wiki/Getting_started_with_virtualization[Getting started with virtualization]
|
||||
Refer to xref:getting-started-with-virtualization.adoc[Getting started with virtualization]
|
||||
|
||||
[[qemu]]
|
||||
== QEMU
|
||||
|
|
@ -18,15 +27,15 @@ QEMU has two operating modes:
|
|||
[[download]]
|
||||
== Download
|
||||
|
||||
QEMU is available on Fedora repository. It can be installed by using https://fedoraproject.org/wiki/dnf[DNF]:
|
||||
QEMU is available on Fedora repository. It can be installed by using xref:dnf.adoc[DNF]:
|
||||
|
||||
....
|
||||
$ su -c "dnf install qemu"
|
||||
....
|
||||
|
||||
|
||||
[[qemu-commands-since-f]]
|
||||
== QEMU commands since F?+
|
||||
[[qemu-commands]]
|
||||
== QEMU commands
|
||||
|
||||
To discover the qemu commands that are installed perform the following:
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue