1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
|
Upload packages and commands
=======================
Prepare source packages
-----------------------
Deb-o-Matic will take into account both source only uploads and source and
binary uploads, while it will discard binary only uploads. Source only uploads
are recommended to avoid waste of bandwidth, so make sure you create packages
by passing ``-S`` flag to ``debuild`` or ``dpkg-buildpackage``.
Then, packages must be copied or uploaded into the directory specified by the
``incoming`` option in the configuration file to let Deb-o-Matic process
them.
In order to save bandwidth while uploading your packages, you could want to
avoid including upstream tarball in the .changes file if it is already
available in the distribution mirrors, Deb-o-Matic will fetch it automatically
for you. In order to do so, you have to pass ``-sd`` flag to ``debuild`` or
``dpkg-buildpackage``.
Multiple uploads of the same packages are allowed, Deb-o-Matic will overwrite
previous builds with new, fresh files.
User-defined fields
...................
sbuild uses several resolvers to determine and install build-dependencies
inside the chroots. Sometimes it is desirable to override the default resolver
to perform some advanced tasks (e.g. using a specific version of a package
which apt-based resolver cannot pick automatically.
In order to do so, you must define the ``XC-Debomatic-Resolver`` in the source
stanza of your ``control file``. For instance, if you want to use the aptitude
resolver, you must use the following syntax:
*XC-Debomatic-Resolver: aptitude*
Prepare command files
---------------------
Deb-o-Matic provides an interface to perform specific tasks into the
Deb-o-Matic ``incoming`` directory such as removing uploaded files or
rebuilding packages. These operations are handled by commands stored in
``.commands`` files, and uploaded into Deb-o-Matic ``incoming`` directory by
using ``dcut`` utility, or by hand.
Using dcut is usually simpler, just launch the following command:
*dcut -U mydebomatic commandfile.commands*
where ``mydebomatic`` is a dput host as described in dput.cf (5) man page, and
``commandfile.commands`` is the file containing the commands to be executed by
Deb-o-Matic.
Multiple commands can be stored in a single ``.commands`` file, but it is
usually safer to issue a single command per file.
.. CAUTION::
If signature checking support is enabled, .commands files must be signed by a
known key, otherwise they will be deleted and no action will be taken.
Remove packages
...............
It could happen some files are kept into Deb-o-Matic ``incoming`` directory,
and you would like to remove them. In order to do so, you must use the ``rm``
command:
*echo "rm foo\*" > foo.commands*
where ``foo*`` is a regular expression matching the files you want to remove.
Rebuild packages
................
You could want to rebuild a package already in the mirrors to see whether it
compiles with newer packages, to analyze its content, and so on. In order to do
so, you must use the ``rebuild`` command:
*echo "rebuild foo_version dist" > foo.commands*
where ``foo`` is the name of the source package you want to rebuild,
``version`` is the version of the package you want to rebuild, and ``dist`` is
the distribution which rebuild the package for.
Deb-o-Matic can also rebuild packages available in other distributions. The
syntax is similar, you just have to indicate which distribution to pick
packages from:
*echo "rebuild foo_version dist origin" > foo.commands*
where ``origin`` is the distribution to pick packages from.
.. CAUTION::
Make sure packages are available in the distribution mirrors, otherwise they
cannot be downloaded and processed by Deb-o-Matic.
Porter uploads
..............
You could want to prepare a porter upload, a binary-only upload which generates
architecture dependent binaries only. Additional information can be found in
`Debian Developer's Reference`_.
In order to do so, you must use the ``porter`` command:
*echo "porter foo_version dist John Doe <jdoe@debian.org>" > foo.commands*
where ``foo`` is the name of the source package you want to rebuild,
``version`` is the version of the package you want to rebuild, ``dist`` is the
distribution which rebuild package for, and the rest of the string is the
address to be used as maintainer field, which is usually the developer who is
preparing the upload.
.. CAUTION::
Make sure packages are available in the distribution mirrors, otherwise they
cannot be downloaded and processed by Deb-o-Matic.
Binary NMU uploads
..................
You could want to prepare a binary NMU (or binNMU) upload, a binary-only upload
which generates architecture dependent binaries only, together with a
changelog entry describing why the upload was needed. Additional information
can be found in `Debian Developer's Reference`_.
In order to do so, you must use the ``binnmu`` command:
*echo "binnmu foo_version dist binNMU_version \"changelog\"
John Doe <jdoe@debian.org>" > foo.commands*
where ``foo`` is the name of the source package you want to rebuild,
``version`` is the version of the package you want to rebuild, ``dist`` is the
distribution which rebuild package for, ``binNMU_version`` is the progressive
binNMU number, ``changelog`` is the reason why the upload was prepared
(enclosed in quotation marks), and the rest of the string is the address to be
used as maintainer field, which is usually the developer who is preparing the
upload.
.. CAUTION::
Make sure packages are available in the distribution mirrors, otherwise they
cannot be downloaded and processed by Deb-o-Matic.
Rebuild packages with extra build-dependencies
..............................................
You could want to rebuild a package already in the mirrors also adding a
specific build-dependency to see whether it compiles with a newer library
version. In order to do so, you must use the ``builddep`` command:
*echo "builddep foo_version dist extrapackage (>= packageversion)"*
*> foo.commands*
where ``extrapackage`` is the name of the package you want to install before
the compilation takes place, and ``packageversion`` is the optional version of
the package you want to install. More than one package can be defined,
separated by commas.
.. CAUTION::
Make sure packages are available in the distribution mirrors, otherwise they
cannot be downloaded and processed by Deb-o-Matic.
Killing builds
..............
You could want to terminate a build you erroneously uploaded, or you do not
want it to complete to avoid wasting too many resources.
In order to do so, you must use the ``kill`` command:
*echo "kill foo_version dist " > foo.commands*
where ``foo`` is the name of the source package you want to terminate its
build, ``version`` is its version, and ``dist`` is the distribution the
package is being built for.
Private repositories
--------------------
Deb-o-Matic can create private repositories, separated from the standard
suites, to be able to upload packages in an isolated environment without
risking to pollute builds with other packages, or to create specialized
repositories for specific purposes.
Deb-o-Matic Private Repositories can be created dynamically by uploading
a package or a command file for a specific suite which has this syntax:
*prefix-name-distribution*
where ``prefix`` is the defined prefix name, ``name`` is an arbitrary name
chosen by the uploader, and ``distribution`` is the target distribution to
build packages from.
.. Links
.. _Debian Developer's Reference: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#porter-guidelines
|
