Hi,
On 10/21/2011 09:59 PM, ext Carsten Munk wrote:
2011/10/21 Eero Tamminen<[email protected]>:
Debugging compiler code generation issues is one of the less
easy things, especially if you've happened to propagate that
mistake also into some other (arm or x86) tools package where
that mis-compile will first appear...
>>
[1] For GCC upgrades I would say that this testing takes months
rather than weeks.
Okay, so that's where OBS's addiction to rebuilds is kind of
interesting as it allows fast feedback on these kind of moves.
While automated rebuilds are nice for API change checks, I would
think a compiler upgrade to be something more than just a (potential)
API upgrade with recompile...
The time I referred doesn't go to rebuilds, but debugging and getting
fixes to all the packages that break when toolchain is upgraded.
Newer GCC's stricter code checks, better warnings and more ambitious
optimization (e.g. in regards to variable aliasing in recent GCCs)
typically reveal more of the bugs hiding the source packages, or
the packages may just be misguided in their use of -Werror.
(I would recommend e.g. colorgcc instead of -Werror if one has
trouble noticing potentially relevant warnings from build logs.)
Let me try and explain some things OBS is capable of.
As I told in another post, when a package changes in OBS (ie, someone
submits a change to the package, or a package it build-depends on
changes) and creates a different result compared to the previous
build, this triggers the rebuild of any package that depends on the
package.
That sounds like potentially huge build slowdown... At least I
hope/assume package submitter doesn't need to wait until build
of everything else depending on it completes.
How much control you have on *when* those rebuilds get done, does
it e.g. happen immediately afterward, during next night or once a week?
Also can you trigger it manually and can you get separate statistics
& logs for the rebuild issues?
And who looks at those rebuild logs and makes sure to debug what
caused the revealed issue and that they get fixed?
If you think in terms of that there's only one OBS project people
accept changes into, a misbehaving compiler will of course nuke the
entire set of binaries with difficult rollback.
So, OBS has a concept called linked projects[1] which is quite useful
to reduce risk and improve QA. In the configuration of a new project,
let's call it Staging, you go in, say, you want to<link
project="some-other-project">.
>
What this does is that it basically makes all source packages in
some-other-project appear in your new project and keep it up to date
with Staging. If you submit a change to Staging, it does not affect
some-other-project.
Staging sound like something all packages use. :-)
I think base build tools (compiler, C-library, Qemu, binutils...) may
need a separate "project" as they can affect all other packages and
finding & fixing issues in them isn't necessarily trivial as every
change requires recompile of everything else.
There's a few different modes of this kind of linked build, called
linkedbuild, which you can adjust in the repository configuration of a
project:
all --- all source packages must be recompiled locally in Staging:
This will basically recompile every single package in the project and
export a full repository with built RPMs. If there's one or more
changes to packages different from some-other-project, these changes
will be included too in the build.
This is useful for let's say, checking if a new compiler breaks
something and run full image builds based on "how would
some-other-project look like with these changes", but additionally
also takes significantly more build power than the next one:
localdep -- reuse binaries from the repository you point to (usually
some-other-project), but rebuild those packages that has been modified
in the project (and hence those) exporting the
modified-from-some-other-project to repository. This takes
significantly less build strength as it doesn't recompile everything
each time, even with simple changes. This is also useful for QA runs.
This is useful to check if one or more packages will cause failures in
other packages. Developers would typically want to take one of these
linked projects to get a set of packages to install into images.
There's also other fun things like block - block="never" means that
never wait for another package to finish building to start building
(ie, 'blocked' state), block="local", only block if it's caused by
another package in same project. There is also "use for build" flag,
which means "utilize the packages inside this projects for building
packages within it". Disable it and it won't wait for other packages
within the repo to build - just run every single packages through once
(read: use entire build cluster's capacity..) [2]
Thanks for the info!
I've used a linked project + no "use for build" to give me a result in
50 minutes on what of the 1400 MeeGo packages would break with Thumb2
enabled
This tells just whether building them breaks, not whether the result
is broken. Does OBS/RPM have some way to specify whether/when to run
test-suites for the build packages?
Btw. Test-suite building & testing is of course also a build speed
issue, as is code documentation building. Proper build machinery
should IMHO have control over both so that they are done e.g. on
suitably scheduled (dedicated?) re-builds.
- I only cared about the individual packages, so no need to
block on each other/depend on each other. Set up a project with new
compiler that the project builds against and you have quite fast
feedack
In sort, OBS offers a lot of facilities that make these kind of
toolchain changes/tool changes a lot less risky - you can get very
early, accurate feedback and easily make images to be sent for QA.
We have that kind of stuff internally in Harmattan (and earlier Maemo
releases), unfortunately that machinery was (AFAIK) never fully opened.
:-/
http://xkcd.com/303/ does come to mind with OBS at times.
Maybe OBS (rebuilds) could adopt it as a logo? ;-)
[1] http://en.opensuse.org/openSUSE:Build_Service_Concept_project_linking
[2]
http://en.opensuse.org/openSUSE:Build_Service_Concept_build_scheduling_strategies
- Eero
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
