Re: holding back the tide

2000-12-31 Thread Brian May
> "Bdale" == Bdale Garbee <[EMAIL PROTECTED]> writes: Bdale> [EMAIL PROTECTED] (Adam Heath) writes: >> Bdale hates dbs, doesn't know what it is Bdale> I don't hate dbs. I just get annoyed when packages with Bdale> complicated build-time patching schemes won't build. My B

Re: holding back the tide

2000-12-31 Thread Bdale Garbee
[EMAIL PROTECTED] (Adam Heath) writes: > Bdale hates dbs, doesn't know what it is I don't hate dbs. I just get annoyed when packages with complicated build-time patching schemes won't build. My sense is that each of these schemes increases the probability of build-time failures by deferring wor

Re: holding back the tide

2000-12-30 Thread Adam Heath
On Sat, 30 Dec 2000, Ben Collins wrote: > > There was no alternative system, when I "designed" the dpatch > > system. The code duplication is needed, because a .dpatch is > > self-contained. For most cases it calls patch with the .dpatch file as > > the patch file. Other commands are run after appl

Re: holding back the tide

2000-12-30 Thread Ben Collins
On Sun, Dec 31, 2000 at 01:05:23AM +0100, Matthias Klose wrote: > Adam Heath writes: > > Bdale hates dbs, doesn't know what it is, so I don't trust his assement of > the > > issue. I never said glibc nor gcc use dbs. They use a system like dbs, > one I > > feel is incorrect(each .dpatch syst

Re: holding back the tide

2000-12-30 Thread Matthias Klose
Adam Heath writes: > Bdale hates dbs, doesn't know what it is, so I don't trust his assement of > the > issue. I never said glibc nor gcc use dbs. They use a system like dbs, one > I > feel is incorrect(each .dpatch system includes code to apply the patch, > which, > I feel, is code dup

Re: holding back the tide

2000-12-30 Thread Adam Heath
On Sat, 30 Dec 2000, Branden Robinson wrote: > On Sat, Dec 30, 2000 at 12:02:53PM -0600, Adam Heath wrote: > > > Adam Heath, please consider helping the gcc maintainer do some DBS > > > surgery, > > > because it is DBS that is keeping gcc from building. > > > > Branden, do some fucking research

Re: holding back the tide

2000-12-30 Thread Matthias Klose
Branden Robinson writes: > > If I'm wrong, fine. Matthias sent me a mail that said this problem should > be fixed with today's dinstall run. I said, that I uploaded new packages. But with new package names ... Let's see when they arrive in testing.

Re: holding back the tide

2000-12-30 Thread Branden Robinson
On Sat, Dec 30, 2000 at 12:02:53PM -0600, Adam Heath wrote: > > Adam Heath, please consider helping the gcc maintainer do some DBS surgery, > > because it is DBS that is keeping gcc from building. > > Branden, do some fucking research next time, before you place blame. Bug > 80843 even proves it

Re: holding back the tide

2000-12-30 Thread Adam Heath
For the record, dbs does NOT have this problem with tar changing options for bzip2. It uses bzip2, gzip, compress(or whatever) directly. BEGIN GEEK CODE BLOCK Version: 3.12 GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS-- PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z

Re: holding back the tide

2000-12-30 Thread Adam Heath
On Fri, 29 Dec 2000, Branden Robinson wrote: > severity 80842 serious > severity 80843 serious > thanks > > gcc won't build on arm, so XFree86 won't build on arm, so XFree86 can't go > into testing, so LOTS of things can't go into testing. > > Adam Heath, please consider helping the gcc maintain

Re: holding back the tide

2000-12-30 Thread Philip Blundell
Branden Robinson wrote: >gcc won't build on arm, so XFree86 won't build on arm, so XFree86 can't go >into testing, so LOTS of things can't go into testing. The latest "2.95.3" gcc ought to be OK on ARM. I think it should be in woody soon if it isn't already. p.

Re: holding back the tide

2000-12-30 Thread Ben Collins
On Fri, Dec 29, 2000 at 11:31:41PM -0500, Branden Robinson wrote: > severity 80842 serious > severity 80843 serious > thanks > > gcc won't build on arm, so XFree86 won't build on arm, so XFree86 can't go > into testing, so LOTS of things can't go into testing. > > Adam Heath, please consider help