File: README

package info (click to toggle)
xbuilder 1.0.1%2Bnmu2
  • links: PTS
  • area: main
  • in suites: bookworm, forky, sid, trixie
  • size: 224 kB
  • sloc: sh: 331; perl: 300; makefile: 7; awk: 3
file content (153 lines) | stat: -rw-r--r-- 5,775 bytes parent folder | download | duplicates (3)
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
This package contains various scripts and utilities for setting up a
batch cross-builder instance 'xbuilder' and bootstrapping a new
architecture 'dimstrap'.

*xbuilder*
The batch cross-builder is very stupid and does not set up any sort of
proper build daemon. It just runs through a list of source packages,
attempting to cross-build each one for a single host architecture. It
can do this for multiple 'flavours' of distro and suite (debian
testing, plus ubuntu raring, for example). The tool can be set to
build with sbuild, xdeb or pdebuild-cross. 

A script (buildlogs-summarise) will parse all the logs and make a nice html
table summarising the results into 'succeeded/failed/build-deps
unsatisfiable'.

This tool was originally written to generate
https://people.linaro.org/~wookey/buildd/


*Dimstrap* 
Dimstrap runs sbuild cross-builds on a list (of source packages,
annotated with profile stages), using the given build-profiles if
specified. If builds succeed then they are uploaded to a repository in
order to be used in subsequent builds.

This tool has largely been superseded by 'rebootstrap'. See
http://wiki.debian.org/rebootstrap


Getting started
---------------

Install xbuilder package.

Decide where you will store your files. xbuilder puts everything below
'Current Working Directory' so run it in the right place. The default
config assumes that /srv/buildd is where package lists will go and
where xbuilder will be run. (mkdir /srv/buildd,  make it writeable by you) 

Set the package buildlist in /etc/xbuilder.cfg
buildlist=/srv/buildd/buildlist-debian-minimal
Also set the host arch (arch to build for) and the distro and
chrootname passed to sbuild.

You can also specify an extrarepository to be passed to sbuild.

You can create a minimal package list with:
sudo debootstrap --print-debs testing /tmp/testing http://http.debian.net/debian | tr ' ' '\n' > debootstraplist


xbuilder
--------

A script to crossbuild a set of packages. It supports sbuild multiarch
crossbuilding by default, but can also be set to run crossbuilds with
the older xdeb or pdebuild-cross tools, which back in 2012 would build 
a larger proportion of packages. 

xbuilder will use the list of packages given in the file specified in 
/etc/xbuilder.cfg, download the source and run the crossbuild on it
in the specified chroot, if using sbuild or pdebuild-cross or locally
in the case of xdeb.

The output is a set of build packages and logfiles. Under the current
directory in 'build/<type>/' and 'logs/<type>/<timestamp>/' respectively. 
Where <type> is the build method used (sbuild, xdeb, pdebuild-cross),
and <timestamp> is the date-time that the xbuilder run was started
(e.g. 20131104-1423).

You can put files anywhere and it should work, 
The default setup assumes that a /srv/buildd dir will be used to store
filelists.

xbuilder can be run as:
xbuilder <configfile> 
so that it is easy to set up multiple build flavours. 'buildd-run'
provides an example of doing a series of runs, one for each flavour,
using a series of config files.

The examples dir has examples for cron configs to run such jobs daily. 

xbuild-create-chroot
-------------------
Yet another chroot-creation script which just wraps
sbuild-createchroot with suitable runes for a standard cross-build
environment.


sbuildlogs-summarise and buildlog-summarise
-------------------------------------------

buildlog-summarise parses sbuild or rebuildd logfiles with filenmaes of the
form package_version-suite-arch-date-time.log
(Both the packages and suites can contain '-' too)

sbuildlogs-summarise parses sbuild logs called <package>.log

(yes, these scripts should be merged!)

They generate a webpage listing the latest builds of each package and
the status of that build (OK, FAILED, Dependencies failed, No source),
with info on what went wrong and summary counts. The lists can be
filtered by a reprepro package list to make different summaries such
as 'bootstrap' package-set and 'everything'. See the Makefile and
sync-buildlogs scripts in the examples dir to see how it can be used.

It is written in perl (which was approximately 100 times faster than
the initial awk implementation!)

buildd-sync
-----------
Is a script to run buildlogs-summarise on a set of logfile dirs and rsync
the results to a server to make them public. 


dimstrap
--------

The dimstrap script is a very simple-minded tool which runs a
cross-build (using sbuild) on a list of packages (or a single package
given on the command line), and uploads the results to a reprepro
repository if successful.

Things needed to make this work:
* A reprepro repository for the built packages to be uploaded to, set up
with an incoming rule and package signing key.
* ssh access to the machine so that upload processing can be kicked.
* A chroot to do the builds in, configured to have the above repository
as an apt source, and with the key installed 
* Local dupload configuration rule pointing to the above repository

Config for all that is in /etc/dimstrap.cfg

If called as dimstrap <package> then it will build the single package
given on the command line.

If called as dimstrap it will looks for a file called pkgorder in the
hard-coded directory from the config file and run through the builds
in that file in order.

The package list (pkgorder) is off the form 
packagename  [profile]

i.e a bare packagename to build and an optional profile name to use in
the build. 

Note that The profile will currently (Jan 2013) be ignored unless you
have a patched sbuild and dpkg. And even then apt knows nothing about
profiles and thus will ignore it too so build-dep failures are likely.
In practice profile builds need to be done manually until the spec is
agreed and sbuild, apt and dpkg are all updated.