All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@oss.sgi.com>
To: Jay Carlson <nop@nop.com>
Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: stable binutils, gcc, glibc ...
Date: Sat, 14 Oct 2000 17:09:28 +0200	[thread overview]
Message-ID: <20001014170928.B6499@bacchus.dhis.org> (raw)
In-Reply-To: <KEEOIBGCMINLAHMMNDJNKECACAAA.nop@nop.com>; from nop@nop.com on Sat, Oct 14, 2000 at 10:51:37AM -0400

On Sat, Oct 14, 2000 at 10:51:37AM -0400, Jay Carlson wrote:

> Hey, don't blame me for the 2.0.6->2.0.7 version bump.  I just grabbed the
> biggest version number on oss.sgi.com at the time and made my *trivial*
> patches to add softfloat to the build.
> 
> Let me say that again: 2.0.7 is NOT MY FAULT.

I didn't blame you - I didn't even know how came up with 2.0.7-mips.  When I
receive bug reports against the various 2.0.7 incarnations I just usually
find that they're that particular 2.0.7 version has bugs which were fixed
eternities ago.

2.0.7 as used by the distributors is probably a reasonably sane libc.

Do your softfp patches somehow cause problems with hardware fp machines?
If not we could throw all things together.

> Seriously, I think the best thing we can do in this situation is start
> assigning our own linux-mips version numbers to combinations of upstream
> sources and our patches.  So, we'd have something like:
> 
>   glibc 2.0.6 + 05lm patches (whatever) == glibc2.0.6 delta 1.0
>   glibc 2.0.6 + 06lm patches (whatever) == glibc2.0.6 delta 1.1
> 
>   egcs 1.0.3a + ralf's current patches == egcs 1.0.3a delta 1.0
>   egcs 1.0.3a + ralf's patches tomorrow == egcs 1.0.3a delta 2.0
> 
>   binutils 2.8.1 + standard patches == binutils 2.8.1 delta 1.0
>   binutils 2.10.x on 20001014 == binutils 2.10.x delta 1.0
>   binutils 2.10.x on 20001015 == binutils 2.10.x delta 2.1
> 
> We need to give *names* to the versions of the software we're testing
> against.  I haven't bothered trying a world rebuild against gcc 2.96.x
> because telling people it worked wouldn't mean anything.  Other people would
> not know that they could reproduce my success by getting the same bits as
> me.
> 
> What I really want to hear is: "I rebuilt gcc, binutils, the kernel,
> modutils, and GNU fileutils using gcc 2.96 delta 7.3, binutils 2.10.x delta
> 5.2, and glibc 2.1.95 delta 1.0", and then know EXACTLY how to reproduce
> that at home.  Just saying "current CVS with patches" doesn't help with
> reproducibility.

Actually I'm trying to kill this entire naming problem by getting all
patches back to the respective maintainers.  Result:  no pending patches
for cvs binutils, only tiny ones for glibc-current and egcs-current.

Naming the patches is a nice idea but frequently I find my own patches
again on some server with creativly changed names.  There is just nobody
who controls the namespace for those patches.

  Ralf

  reply	other threads:[~2000-10-14 15:09 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-14  5:13 stable binutils, gcc, glibc Jun Sun
2000-10-14  3:55 ` Ralf Baechle
2000-10-14  4:21   ` Ralf Baechle
2000-10-14 10:57   ` Florian Lohoff
2000-10-14 14:51   ` Jay Carlson
2000-10-14 14:51     ` Jay Carlson
2000-10-14 15:09     ` Ralf Baechle [this message]
2000-10-14 16:11       ` Jay Carlson
2000-10-14 16:11         ` Jay Carlson
2000-10-14 16:29         ` Bradley D. LaRonde
2000-10-14 16:29           ` Bradley D. LaRonde
2000-10-16  0:35           ` Ralf Baechle
2000-10-16  1:33             ` Mike Klar
2000-10-16  1:33               ` Mike Klar
2000-10-16 11:26               ` Jay Carlson
2000-10-16 11:26                 ` Jay Carlson
2000-10-16 11:30                 ` Ralf Baechle
2000-10-16 12:00                 ` Ralf Baechle
2000-10-18  1:59                   ` Jay Carlson
2000-10-18  1:59                     ` Jay Carlson
2000-10-18 20:31                     ` Ralf Baechle
2000-10-14 16:11       ` Jay Carlson
2000-10-14 16:11         ` Jay Carlson
2000-10-14 16:12         ` Ralf Baechle
2000-10-14 16:22           ` Bradley D. LaRonde
2000-10-14 16:22             ` Bradley D. LaRonde
2000-10-14 23:47           ` Keith Owens
2000-10-16  1:07             ` Ralf Baechle
2000-10-16  7:00               ` Alan Cox
2000-10-16  7:00                 ` Alan Cox
2000-10-14 10:55 ` Florian Lohoff
2000-10-14 12:41   ` Ralf Baechle
     [not found]   ` <Pine.LNX.4.21.0010140730280.17430-100000@spawn.hockeyfiend.com>
2000-10-14 14:25     ` Ralf Baechle
2000-10-14 17:54       ` Florian Lohoff
2000-10-16 15:41 ` Maciej W. Rozycki
2000-10-18  4:04 ` The initial results (Re: " Jun Sun
2000-10-18  1:33   ` Florian Lohoff
2000-10-18  9:20     ` Jun Sun
2000-10-18  2:25       ` nick
2000-10-18  9:18       ` Florian Lohoff
2000-10-18 12:27         ` Ralf Baechle
2000-10-18  1:57   ` Ralf Baechle
2000-10-18 12:30     ` Florian Lohoff
2000-10-18 22:37       ` Ralf Baechle
2000-10-18 11:42   ` Geert Uytterhoeven
2000-10-18 17:15     ` Jun Sun
2000-10-20 14:55       ` Geert Uytterhoeven
2000-11-06 11:43   ` Jay Carlson
2000-11-06 11:43     ` Jay Carlson
2000-10-20 11:09 ` Andreas Jaeger
2000-10-20 12:03   ` Jay Carlson
2000-10-20 12:03     ` Jay Carlson
2000-10-21  1:24     ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20001014170928.B6499@bacchus.dhis.org \
    --to=ralf@oss.sgi.com \
    --cc=linux-mips@fnet.fr \
    --cc=linux-mips@oss.sgi.com \
    --cc=nop@nop.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.