June 03 - June 10: Check which packages is known as multiarch or easily to be 
crossbuilt and test them. In this step I will ask for people that have already 
patched these packages to speedup the process.

The objective of this week was to raise up what are the packages that I have to
make patchs and fill bugs for them in the next weeks. So, I have to define
which packages of the minimal-build-system is ready for crossbuild, which are 
arch:all (and we don't need to crossbuild), which packages we need to crossbuild 
to satisfy all buld-dependencies and which are multiarch:foreign
(and we don't need to crossbuild). 

A very importante discussion raised in the irc channels (#multiarch and #debian-bootstrap) 
was if the arch:all packages
should be used to satisfy build-deps or not, even if they are not m-a:foreign. As the
conclusion of this discussion, we have to consider that arch:all packages can't be used 
to satisfy build-dependencies if they are not m-a: foreign. In my humble opinion, this
makes sense, since just m-a: foreign packages can be used to satisfy build-dep of other
architectectures in the multiarch specification [1]. If an arch:all package should be 
used to satisfy build-dep of foreign
architectures, we just have to add the m-a:foreign field to this package. Unfortunly
nothing is document about this discussion yet, except a discussion on #multiarch.

Also, I had a very important discussion with josch on irc (#debian-bootstrap). The main conclusions
I took from it was:

--> Even if we consider that all packages of the foreign architecture are built, we still cannot 
crossbuild all sources needed to bootstrap a system in theory. This is because we don't have sufficient
multiarch information in the packages. For example, the autoconf is an arch:all package that has not any
multi-arch information and a lot of package build-depend it (eg. acl:armel build-dep autoconf:armel). 
With this in mind, the first thing we have to solve is to add sufficient multiarch information on package
that enables the crossbuild process in theory. 
--> The second step is, considering we have the necessary multiarch information on the packages, break all
build-dependency cycles of the packages need to the bootstrap. After this step, we can use botch 
to generate a build order list. A more detailed discussion about the cyclic build-dependency is in [2]
--> With the build order list on hands, we can execute the bootstrap process using the automated bootstrap
tool that I'm going to build.  
--> Finally, in the last step we have to confirm that the minimal build system is sufficient to build all
packages nativally. 

Considering this, I'm going to make a small change on the schedule 
In the next week (June 10 - June 17), instead of "Start File 
bugs of the packages that have failed to crossbuild.", I'm going to "Add the multiarch
information needed to enable the theorical crossbuild of all packages needed considering" 

As a result of this week, I created a document with tables to datail the currently stat of 
the importante packages for the bootstrap problem. This document can be found in [3]. The 
script at [4] was used to generate it. During all the GSoC project I intend to use this
script to generate detailed information about the currently state of the packages.
Botch [5] is used in the script to get the theoretical information
about the packages. 

Fortunly, this week finished accordingly with the schedule.

Again, I would like to thanks josch, wookey and pehjota for all the efforts trying to help me.

references:
[1] https://wiki.ubuntu.com/MultiarchSpec
[2] http://wiki.debian.org/DebianBootstrap#Circular_dependencies.2Fstaged_builds
[3] http://www.lrc.ic.unicamp.br/~alkmim/debian/GSoC2013/Documents/multiarch-crossbuild-status/host-and-build-packages-available/bootstrap-status-at-Jun-10-Jun.pdf
[4] http://www.lrc.ic.unicamp.br/~alkmim/debian/GSoC2013/scripts/generate_packages_state_host_available.sh
[5] https://gitorious.org/debian-bootstrap/botch