Bug#743697: marked as done (qa.debian.org: [jenkins.d.n] please run rebootstrap)
Your message dated Sat, 26 Apr 2014 20:49:48 +0200
with message-id <20140426184948.GA25861@alf.mars>
and subject line Re: qa.debian.org: [jenkins.d.n] please run rebootstrap
has caused the Debian Bug report #743697,
regarding qa.debian.org: [jenkins.d.n] please run rebootstrap
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
743697: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743697
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: qa.debian.org
Severity: wishlist
User: qa.debian.org@packages.debian.org
Usertags: jenkins.d.n
Hi Holger,
It would be nice if jenkins could run rebootstrap, a QA effort aiming to
test the very early stage for bootstrapping new and old architectures.
This is part of a larger goal called "bootstrappable Debian".
I set up a git branch "rebootstrap" at
git.debian.org:/git/users/helmutg/jenkins.debian.net.git that tries to
provide a initial configuration for jenkins to run rebootstrap (also
attached). Help with finishing this draft is welcome.
To get an idea of what is needed I'll write down a bit of the goals and
use cases:
* Until now only the gcc/eglibc dance is implemented and it takes at
most 3h. If successful, this will take longer in future.
* There are no inter-job dependencies. They can all run in parallel.
* The most valuable build artefact is the build log. Optionally the
resulting packages can be saved (by passing RESULT=/some/directory).
* Rebuilds should happen at least once per gcc/eglibc package upload,
being able to externally trigger sets of jobs would be nice. Most
often I can tell which job configurations are affected by a commit to
rebootstrap.git.
* The build logs contain lines matching /^progress-mark:\d+:.*/ to give
a rough clue on where they fail. Larger numbers are better.
* As future extension running gcc-4.9 and multilib bootstraps would be
nice. That also means that generating job configurations from a
feature space (architecture, gcc version, multilib enabled) would be
nice.
* It is essential to run many architectures in parallel to determine
whether a particular build error is architecture-specific or generic.
* The main goal of this effort is to actually fix things. Examples:
#742358 #742539 #743342 #743676 #742640
If you have any questions concerning this effort. The natural points of
contact are me (mail) and #debian-bootstrap (or maybe #debian-qa) on
oftc.
Helmut
- defaults:
name: rebootstrap
description: 'Verfy bootstrappability of Debian architectures'
scm:
- git:
url: 'git://anonscm.debian.org/users/helmutg/rebootstrap.git'
branches:
- master
builders:
- shell: '/srv/jenkins/bin/chroot-run.sh sid ./bootstrap.sh HOST_ARCH={architecture} {params}'
publishers:
- email:
recipients: helmutg@debian.org
- project:
name: rebootstrap
jobs:
- 'rebootstrap_arm64':
architecture: 'arm64'
- 'rebootstrap_m68k':
architecture: 'm68k'
--- End Message ---
--- Begin Message ---
On Sat, Apr 05, 2014 at 01:18:29PM +0200, Helmut Grohne wrote:
> * Until now only the gcc/eglibc dance is implemented and it takes at
> most 3h. If successful, this will take longer in future.
Takes up to 6h now.
> * There are no inter-job dependencies. They can all run in parallel.
Works.
> * The most valuable build artefact is the build log. Optionally the
> resulting packages can be saved (by passing RESULT=/some/directory).
Logs being saved and easily accessible from the web.
> * Rebuilds should happen at least once per gcc/eglibc package upload,
> being able to externally trigger sets of jobs would be nice. Most
> often I can tell which job configurations are affected by a commit to
> rebootstrap.git.
External triggers via git commits in working order.
> * The build logs contain lines matching /^progress-mark:\d+:.*/ to give
> a rough clue on where they fail. Larger numbers are better.
logparse in working order.
> * As future extension running gcc-4.9 and multilib bootstraps would be
> nice. That also means that generating job configurations from a
> feature space (architecture, gcc version, multilib enabled) would be
> nice.
Works.
> * It is essential to run many architectures in parallel to determine
> whether a particular build error is architecture-specific or generic.
Many architectures are configured.
The overall conclusion is that this bug is solved. Big thanks to Holger
for his extensive support.
Helmut
--- End Message ---
Reply to: