I've expanded the notes on using bzr for toolchain development here:
https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips
It's now much more step-by-step and includes notes on how long
operations take and how big they end up on disk or the network.
-- Michael
Hey
Matthias kicked an armel rebuild of Ubuntu main with a gcc-4.4 + Linaro
diff package. The rebuild copy-archive is visible at:
https://launchpad.net/ubuntu/+archive/test-rebuild-20100707
The failed logs are at:
https://launchpad.net/ubuntu/+archive/test-rebuild-20100707/+builds?build_t…
@Steve, you had offered help in reviewing the i386/amd64 rebuilds in
the past (and I think Michael Hope was working on these); I would very
much take help in reviewing the armel issues. Is this something the
Foundations team could help with?
I'd like to discuss organizing this review a bit.
* First, we need to make sure we don't review the same build logs
multiple times; the rebuild isn't over and builds are going to
continue showing up; Matthias told me new build logs will show up at
the top, so we only need to note the last package we reviewed.
* We need some place tracking the build logs which we skipped (for
which we didn't file a bug) and/or note last reviewed package; I
propose to note this down in a wiki page.
* For now, we should skip openjdk / java related issues; openjdk needs
some bug fixing before we can consider using it on armel. Such
issues should be documented along other instructions in the
aforementioned wiki page.
* I think we should skip packages which FTBFS on x86. Do we actually
compare build logs before classifying these?
* We should file bugs with some standard tags, perhaps linaro + armel?
* I would like us to develop helpers to analyze build-logs; perhaps
Lucas Nussbaum has something since he manages to analyze the grid5000
rebuild logs decently. Ideally, these tools would also allow
assigning build log reviews to people, leaving comments and such.
Comments welcome!
Cheers,
--
Loïc Minier
Hi there. What's the appropriate format for a ChangeLog entry when
closing out a issue, or when merging in a change from another branch?
My best guess was:
2010-07-12 Michael Hope <michael.hope(a)linaro.org>
lp:602171
* gcc.target/i386/pr9771-1.c: Merge r159776 from FSF GCC into the
Linaro branch.
* gcc.target/arm/frame-pointer-1.c: Likewise.
Original entry:
2010-05-24 Paul Brook <paul(a)codesourcery.com>
* gengtype-lex.l: Add HARD_REG_SET.
* expr.c (expand_expr_real_1): Record writes to hard registers.
* function.c (rtl_data): Add asm_clobbers.
* ira.c (compute_regs_asm_clobbered): Use crtl->asm_clobbers.
(ira_setup_eliminable_regset): Remove regs_asm_clobbered.
Use crtl->asm_clobbers.
Note that the change was already present but the test cases hadn't
been updated.
In this case I back-ported Subversion revision 159776 from the FSF GCC
into the Linaro branch to fix a Launchpad ticket that was assigned
against me. Paul Brook did the original work. The note at the bottom
is due to most of the fix already existing in the Linaro branch.
-- Michael
