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] |
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] |