Bug#766708: counterfeiting the summary of the bootstrap sprint
On Thu, 04 Dec 2014 20:41:57 +0100 Matthias Klose <doko@debian.org> wrote:
> So in the last email Wookey enumerates a lot of things what he did during the
> last months. Maybe he should have mentioned his ballerina lessons used for his
> performances during the DebConf talks too. However ever all of these have in
> common, that this has nothing to do at all with the work he committed to do.
>
> Further he cites a paragraph from the debian-bootstrap sprint summary, which reads:
>
> """
> The report from that meeting
> https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results says:
> ----------
> 3.13. Multiarch cross-toolchains vs single-arch cross-toolchains
>
> This contentious issue was discussed, and is partly covered under other
> headings. Wookey prefers the multiarch builds, Doko prefers the single-arch
> bootstrap builds. We agreed that either provides useful cross-toolchains. It's
> not clear whether it's easier to fix the Ubuntu cross-toolchain-base packages
> to do a bootstrap build in Debian, or to fix the blockers for multiarch builds
> in the archive. Whichever is working first should get uploaded.
> """
Good summery, and I also prefer multiarch builds and I also maintain
it for mips64el.
And more:
multiarch builds can also bootstrap. I bootstrapped mips64el in this way,
and now, it need some dirty hacks,while
if we wish, we can make it much more clean.
As I noticed that, the argument that to remove multiarch builds
includes (wish I am right):
> 1. multiarch builds make single-arch some more difficult, and maintain 2 way is not a esay way.
Yes, while it is more difficult not impossible.
> 2. multiarch builds needs cross depends, which is hard for Debian infrastructure
Yes, this is a problem for now, while I think this is the direction we
are stepping for.
> 3. Bootstrap need single-arch
No, this is wrong, we can bootstrap Debian with multiarch builds.
The steps are:
1. cross binutils - we have it in archive.
2. stage1 gcc, with only C support, and libgcc is also disabled.
3. stage1 glibc - it is a fake libc6, we can patch glibc to archive it.
4. linux-libc-dev - we can use stage1 gcc to get it. src:linux
support it now.
5. stage2 gcc - it has shared and static libraries support now
and libgcc etc are still disabled
6. stage2 glibc - now we can use stage2 gcc to build glib, and we can get
libc6(-dev) and multilib libc6.
7. stage3 gcc, now we can build a gcc with C,C++,Go, D and fortran support.
In every step, we get some DEBs, and we can install some of them, and
go to the next step.
Of course, these steps may make some trouble for packages like
gcc-4.8-armhf-cross.
If we split it to more than one source packages, it is still possible when
infrastructure support.
If you repack these DEBs, it also can archive the goal of current
gcc-4.8-armhf-cross.
By the way, if we remove single-arch build, this package will be much
more clean than now,
lots of hacks can be removed from current gcc-4.9 and make life more happy.
>
> According to
> https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results?action=diff&rev1=30&rev2=31
> the last sentence was added on Aug 29 during DebConf, long after the sprint
> happened, with a commment "must be almost the final review", without mentioning
> anything. I call this counterfeiting the summary of the sprint. I assume this
> helped to convince other people to sneak in these packages into Debian. What is
> this if not "bad faith"?
>
> Again, the rest of the email talking about willing to work together doesn't
> match the his actions at all.
>
> Matthias
>
>
Reply to: