This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ct-ng -> git repos instead of single patches


Hi,

[last mail was not complete, continuing...]

On Mon, Aug 2, 2010 at 10:14 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> http://www.metux.de/download/oss-qm-project-2010050101.pdf
>
this does not say anything about trust, the source of patches, nor
their quality. Has it been made by the project developers ? if so, why
has it not been integrated ? Has it been made by someone who had the
slightest knowledge of how the patched software work ? or by a student
in internship working overtime for an integrator ?

I'd be temped to only allow in ct patches which have been submitted to
upstream, with link to the associated bug report and a distinguishable
author. Moreover, upstream package should be tagged enough for a
lambda user not to send  bug-report to the upstream for a patch broken
in ct. Harvesting patches to harvest patches (as Yann seems to be fond
of) should be the last thing to do. I'm sure he would have been super
happy if I had included 42 differents patches with the upgrade patch
to gcc 4.5.1. He would certainly never have check they were all fully
valid; he is not a gcc devs, neither am I. Finally, I could have
rooted every gcc 4.5.1 build with these patches.

As a quick example of my point, most of the patch of uClibc 0.9.30.2
have been copied in a single shot from buildroot. Buildroot commit log
is "Everything on the 0_9_30 branch since the release (0.9.30.3 to
be)". So that why currently someone building a toolchain based on
uClibc 0.9.30.2 really has 0.9.30.3. I'd suspect that currently, Yann
does not provide uClibc 0.9.30.3 because "ct-ng" 0.9.30.2 is already
0.9.30.3.

Now, let's look at what patch are applied to uClibc 0.9.30.2:

100-fix-gethostent_r-failure-retval.patch:
110-arm_fix_alignment.patch:
120-rm-whitespace.patch:
130-gnu89-inline.patch:
 -> from gentoo, no patch reason, not in upstream

140-pack-netinet-structs.patch
 -> patch from Joachim Nilsson, no more info about why it has not been
submitted upstream

150-LT-pthread_atfork-unhide.patch
 -> fix perl build, ok

160-Make-use-of-macros-from-sys-asm.h-in-crt1.S.patch
 -> fix mips+nptl boot, AFAIK, nptl is not in 0.9.30.2: trash

170-Makefile.in-Make-install_dev-depend-on-install_runti.patch
 -> "help" (ie. not "fix") // build, not critical: trash

180-Unbreak-build-for-sparc-on-some-config-s.patch
 -> unbreak sparc build: ok

190-avr32-add-varargs-handling-of-prctl-syscall.patch
 -> patch for an atmel dev, but prctl(2) is hardly critical: trash

200-clean-up-O_CLOEXEC-handling.patch
 -> looks functionnal change, no build failure reported: trash

210-fix-make-install-host-utils.patch
 -> seems to fix a build: ok

220-fstatat-fix-up-behavior-on-32-64-bit-hosts.patch
 -> behavioral change: trash

230-getdents-Fix-mips64-build.patch
 -> mips64 build fix: ok

240-host-utils-depend-on-headers.patch
 -> build fix: ok

250-libc-Fix-typo-in-include-rpc.patch
 -> fix typo: trash

260-libm-enable-log2f-and-exp2f.patch
 -> functional change: trash

270-malloc-fix-race-condition-and-other-bugs-in-the-no-m.patch
 -> fix race condition: trash

280-rpc-fix-typo-in-version-mismatch-msg.patch
 -> typo: trash

290-blackfin-nommu-fork-stub.patch
 -> provide fork(2) on blackfin: trash

>From the patches of unknown origin, author or purpose, there is 2
worth being pulled in. From buildroot set, there is barely 5 patches
actually fixing build issue (out of 14), the rest is
nitpicking/runtime change.

The funniest for the end:  120-rm-whitespace.patch : this is pure
whitespace change... I don't know if I should laught or cry...

 - Arnaud

ps: no, I'm not paranoid, just careful.

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]