[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#766708: counterfeiting the summary of the bootstrap sprint

I have a suggestion:

Wookey, can you use package name like cpp-4.9-armhf instead of
cpp-4.9-arm-linux-gnuabihf ?
Then we can have both schemes in archive?

Wookey, can you remove cross-gcc-* packages from archive temporarily?

Doko, can you merge the attached patches?

In 0006-gcc-pkg-rename.patch, and when define
with_deps_on_target_arch_pkgs, gcc-4.9-ARCH will be generated instead
of gcc-4.9-<triplet>.

On Fri, Dec 5, 2014 at 11:28 AM, YunQiang Su <wzssyqa@gmail.com> wrote:
> 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

YunQiang Su

Attachment: 0001-libgcc-4.9-dev-depends-equal.patch
Description: Binary data

Attachment: 0002-gcc_cross_multiarch.patch
Description: Binary data

Attachment: 0003-allow-no-biarch.patch
Description: Binary data

Attachment: 0004-gxx-crossbase-substvar.patch
Description: Binary data

Attachment: 0005-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch
Description: Binary data

Attachment: 0006-gcc-pkg-rename.patch
Description: Binary data

Reply to: