Thread: Re: [PORTS] RedHat6.0 & Alpha
> > IMHO a 6.5.2 release with all of the necessary alpha patches
> > already in the distribution source tree is a much cleaner, clearer
> > solution, for distribution packagers, average users, and
> > compile-it-yourself-people.
> I think he was going to generate a 6.5.2 by back-patching, not
> distributing a new patch to make 6.5.2.
Yup.
OK, I'm trying to do this to help the Alpha folks, in such a way that
it helps the Alpha-linux-RH folks to get RPMs also. Having a 6.5.2
which does not run on Intel or Sparc does not help. Having a 6.5.2
which has diverged from the 6.5.x tree in unknown ways does not help.
Having us decide by consensus the appropriate model for s/w
development (main tree with changes progressing to a full release,
branch tree to carry maintenance changes) and then at the first
opportunity step away from that seems counterproductive in the
extreme. We ran into this same discussion during v6.4.x, and we're
doing it again.
If y'all can't maintain two branches, then let's stop doing it. otoh,
we can't do maintenance releases without a stable branch, so we'd
better think about it before giving up.
I've offered to help, much more than I should bother with. I'll leave
it to other Alpha stakeholders to decide what they want. I should
point out that I offered to our RedHat contacts to try to marshall an
Alpha-ready build, but so far it's like herding cats.
And *really*, if we have 3.5MB of diffs, who are we kidding about
knowing where they all came from and what they are doing? Backpatching
or developing patches on a clean 6.5.1 release is the only thing to do
for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months
for RPMs.
My $0.03 ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> And *really*, if we have 3.5MB of diffs, who are we kidding about > knowing where they all came from and what they are doing? Backpatching > or developing patches on a clean 6.5.1 release is the only thing to do > for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months > for RPMs. OK, let's punt. If someone wants to develop an alpha-only patch for 6.5.1, they are welcome. We certainly had enought beta time to allow Alpha people to address this. After the final minor release is just too late. Sorry. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> And *really*, if we have 3.5MB of diffs, who are we kidding about
> knowing where they all came from and what they are doing?
3.5MB of diffs? I must have missed something ... where did those
come from, and what are they?
I agree that no large changes should go into 6.5.x at this point,
but should we be accepting these diffs into the 6.6 branch?
regards, tom lane
> OK, I'm trying to do this to help the Alpha folks, in such a way that > it helps the Alpha-linux-RH folks to get RPMs also. Having a 6.5.2 [snip] > point out that I offered to our RedHat contacts to try to marshall an > Alpha-ready build, but so far it's like herding cats. > And *really*, if we have 3.5MB of diffs, who are we kidding about > knowing where they all came from and what they are doing? Backpatching > or developing patches on a clean 6.5.1 release is the only thing to do > for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months > for RPMs. > My $0.03 ;) I second this. In the last few months, PostgreSQL has really been making progress in the mindshare area -- once, what was written off as being unreliable, buggy, and slow, not to mention feature-lean, is now being touted by many as "commercial quality", "the Free Software equivalent to Oracle", "stable", "reliable", and "fast". I'm all for having the latest and greatest snapshots working on the Alpha -- Woo Hoo, etc, etc. I'm all for the current CVS tree building like a champ on Alpha -- this is good stuff. HOWEVER, if there is a need for a 6.5.x running on Alpha, then 6.5.1 needs to get the Alpha patches (possibly a few other reliability patches -- but, keep the number of patches down to a minimum -- this is still a 6.5.x release -- bug fixing only.) for a 6.5.2, where the advertised bugfixes include the long-awaited Alpha patches. For goodness sakes, Alpha is a major architecture -- this needs to be done right. Make the number of possible variables a minimum -- let's get a patch set working that applies to virgin 6.5.1. If backporting and backpatching is required to do this, in the name of ROBUSTNESS -- by all means -- let's do it. (I say all this after Thomas had to "slap me around" a little -- I have been getting the cart before the horse on some of the RPM issues, and needed a good reminder of just what kind of software package I'm working on! This is an RDBMS -- people will be using this for major data -- like the guy from Australia who e-mailed here not long ago about 6.5 vs 6.4.2, and mentioned that his database had a few MILLION rows -- did anybody catch the significance of that? (Wayne Pierkarski from senet.com.au) Thanks for the wakeup call, Thomas.) Thanks and kudos go the the guys who have made the Alpha port work -- now, let's get a patch set against 6.5.1 that works -- if that proves too difficult, we'll just have to wait until pre-6.6, as Thomas already said. PostgreSQL is kicking major tuples -- let's keep it that way.... My 1.5 cents... Lamar Owen WGCR Internet Radio
Okay, let me get this straight...v6.5 was in beta for, what, 2 months?
And it isn't until *after* v6.5.1 is released that the Alpha guys realized
that "oops, it doesn't work"? And they have a patch that amounts to ~1/2
the size of the current distribution to get this to work?
*rofl*
The stable branch is meant to allow *minor* changes to go into it, and, if
there are enough, to generate a new *stable* distribution. Minor changes
are "we put && instead of || in an if statement that only shows up #ifdef
<feature> is enabled"...or even where a bug is fixed that is based on us
missing an error check that adds a few lines of code.
I have no problems with building a v6.5.2, or .3, or .4, if required...but
a 3.5MB diff does not constitute a 'minor bug fix' and should be merged
into v6.6 only...
On Fri, 30 Jul 1999, Thomas Lockhart wrote:
> > > IMHO a 6.5.2 release with all of the necessary alpha patches
> > > already in the distribution source tree is a much cleaner, clearer
> > > solution, for distribution packagers, average users, and
> > > compile-it-yourself-people.
> > I think he was going to generate a 6.5.2 by back-patching, not
> > distributing a new patch to make 6.5.2.
>
> Yup.
>
> OK, I'm trying to do this to help the Alpha folks, in such a way that
> it helps the Alpha-linux-RH folks to get RPMs also. Having a 6.5.2
> which does not run on Intel or Sparc does not help. Having a 6.5.2
> which has diverged from the 6.5.x tree in unknown ways does not help.
> Having us decide by consensus the appropriate model for s/w
> development (main tree with changes progressing to a full release,
> branch tree to carry maintenance changes) and then at the first
> opportunity step away from that seems counterproductive in the
> extreme. We ran into this same discussion during v6.4.x, and we're
> doing it again.
>
> If y'all can't maintain two branches, then let's stop doing it. otoh,
> we can't do maintenance releases without a stable branch, so we'd
> better think about it before giving up.
>
> I've offered to help, much more than I should bother with. I'll leave
> it to other Alpha stakeholders to decide what they want. I should
> point out that I offered to our RedHat contacts to try to marshall an
> Alpha-ready build, but so far it's like herding cats.
>
> And *really*, if we have 3.5MB of diffs, who are we kidding about
> knowing where they all came from and what they are doing? Backpatching
> or developing patches on a clean 6.5.1 release is the only thing to do
> for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months
> for RPMs.
>
> My $0.03 ;)
>
> - Thomas
>
> --
> Thomas Lockhart lockhart@alumni.caltech.edu
> South Pasadena, California
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Fri, 30 Jul 1999, Thomas Lockhart wrote:
> > > IMHO a 6.5.2 release with all of the necessary alpha patches
> > > already in the distribution source tree is a much cleaner, clearer
> > > solution, for distribution packagers, average users, and
> > > compile-it-yourself-people.
> > I think he was going to generate a 6.5.2 by back-patching, not
> > distributing a new patch to make 6.5.2.
Ok, you lost me on the terminology there then. What exactly is
'back-patching'?
> If y'all can't maintain two branches, then let's stop doing it. otoh,
> we can't do maintenance releases without a stable branch, so we'd
> better think about it before giving up.
I do follow your logic on a stable vs. unstable tree, and can see
the benefit of having it.
> I've offered to help, much more than I should bother with. I'll leave
> it to other Alpha stakeholders to decide what they want. I should
> point out that I offered to our RedHat contacts to try to marshall an
> Alpha-ready build, but so far it's like herding cats.
Yea, it has been like that with the Linux/Alpha port for some
time, including other packages then pgsql alone. :( As for the other Alpha
stakeholders, I have yet to hear from any of them at all in this
disscussion and for a while in any discussion concerning pgsql and
Linux/Alpha. Of course, every now and then, some Linux/Alpha user comes
along and asks why we haven't moved anywhere with pgsql in the last so
long, and gets mad with any answer I try and give them. My conclusion
about Linux/Alpha is that lots of people want the power of the alpha
processor, but don't want to help out and get rid of some of the lingering
sharp edges. They want it to work right out of the box! That leaves things
to a few of us die hards to get everything working, and most of them
focus on more fundamental things, like gcc and glibc, and the applications
end up getting the short end of the stick. Ok, I will get off my soap box
here, back to the trenches....
> And *really*, if we have 3.5MB of diffs, who are we kidding about
> knowing where they all came from and what they are doing? Backpatching
> or developing patches on a clean 6.5.1 release is the only thing to do
> for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months
> for RPMs.
After this discussion and a few tests of my own, I think I had
better change my position on this issue.
First of all, today's snapshot with Uncle G's patches compiles and
runs on Linux/Intel and Solaris/Sparc as well as they do without the
patches on the same snapshot for the most part. Though the patches seem to
break the random regression test on Linux/Intel. Also, today's snapshot
(clean) will not compile on Solaris/Sparc, as there is an extra #endif in
./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
So, this snapshot is in suspect, and it looks like the alpha
patches are as well, at least as far as other platforms go.
My vote would be go back and do a 'alpha' patch off of 6.5.1, and
distribute that to the distribution people to get pgsql running on
Linux/Alpha in the short time. Then, four months or so down the road when
the next release target comes up, we plan to have a version of pgsql that
will run on both Alpha and other platforms. That means Uncle G's patches
need to be checked for what they do to the other platforms.
This would get us a Alpha ready version of pgsql now (there has
been enough delay as it is, we really don't want to wait any more), not
put us out on the limb with a possibly unstable release of pgsql, and
gives us time to get the alpha patches properly tested and integrated into
the main source tree.
As I see it, these are the following things that need to be added
to 6.5.1 to make it alpha ready:
* Uncle G's Alpha patches { which I have }.
* Makefile conditionals for Linux/Alpha { which I can find with
only moderate trouble }.
* Bruce's alignment patches { which I do not have }.
Bruce, if you could get me your alignment patches, then I will try and
apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
ready state. Then we give that patch to debian and RH developers, tell
them to only apply it to thier alpha builds, and that we will have a
universal source tree for all platforms (including alpha) in a few months.
This is simular to what was done (might even still be done) for
the Linux kernel itself. To compile a 2.0.x kernel for Linux/Alpha, one
got the clean source, a set of alpha patches for the same rev level, and
applied them to the clean source to generate an alpha ready kernel source
tree.
Is this a viable idea, or just another horrible kludge?
> My $0.03 ;)
Raising the ante here? :) Well, then this was my four cents!
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
On Thu, 29 Jul 1999, The Hermit Hacker wrote:
> Okay, let me get this straight...v6.5 was in beta for, what, 2 months?
> And it isn't until *after* v6.5.1 is released that the Alpha guys realized
> that "oops, it doesn't work"? And they have a patch that amounts to ~1/2
> the size of the current distribution to get this to work?
>
> *rofl*
Yea, I think it has turned into a bit of a crazy mess. :) I had
meant to do something about Alpha for the 6.5 release, but it came too
soon after school got out to do anything (i.e. when I actually had free
time). Then Uncle G. came along, out of the blue, and fixed everything in
a few days, but then got impatient that we had not applied his patches
after a few more days and then moved on to other conquests. That left us
with patches that worked, which we were grateful for (at least I was), but
provided unknown affects on other platforms and only against an unstable,
in flux snapshot.
Then I tried to see how many differences there were between 6.5.1
and the current snapshot, only to find that the differences were "a lot".
> The stable branch is meant to allow *minor* changes to go into it, and, if
> there are enough, to generate a new *stable* distribution. Minor changes
> are "we put && instead of || in an if statement that only shows up #ifdef
> <feature> is enabled"...or even where a bug is fixed that is based on us
> missing an error check that adds a few lines of code.
Agreed. Uncle G's alpha patches alone break that as they are 62k
in size and touch quite a few files.
> I have no problems with building a v6.5.2, or .3, or .4, if required...but
> a 3.5MB diff does not constitute a 'minor bug fix' and should be merged
> into v6.6 only...
Yea, 3.5MB does not consitute a minor bug fix (maybe for M$ it
does, but lets not go there). And that includes all changes between 6.5.1
and the current snapshot, not just the alpha ones.
So, after reading the emails that arrived while writing my last
one... If I could get my hands on Bruce's alignment patches, then by
Monday, I should be able to have a set of alpha patches against 6.5.1 that
provide a working alpha version for the time being (until 6.6 comes around
and we can clean up the alpha patches and put them in the main tree).
PS. As far as I can tell, us Alpha guys are pretty few in number,
at least those who are actually subscribed to the pgsql-ports and
pgsql-hackers email lists and try and do something for pgsql on
Linux/Alpha. Unfortuntely this "Alpha guy" often finds himself very busy
and his C skills not up to the task of hunting down obscure platform bugs
in a huge mass of code. Something along the lines of "The spirit is
willing, but the flesh is weak." :(
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
I do not want to see any patches commit'd to v6.5.x branch that is
*anything* but a minor bug fix...personally, we had a 2 month beta period
on this...the Alpha related stuff should have been submit'd then, at the
very latest...
Please feel free to work at getting these into v6.6, *before* v6.6 is
released, so that this problem doesn't rear its head again...
On Thu, 29 Jul 1999, Ryan Kirkpatrick wrote:
> On Fri, 30 Jul 1999, Thomas Lockhart wrote:
>
> > > > IMHO a 6.5.2 release with all of the necessary alpha patches
> > > > already in the distribution source tree is a much cleaner, clearer
> > > > solution, for distribution packagers, average users, and
> > > > compile-it-yourself-people.
> > > I think he was going to generate a 6.5.2 by back-patching, not
> > > distributing a new patch to make 6.5.2.
>
> Ok, you lost me on the terminology there then. What exactly is
> 'back-patching'?
>
> > If y'all can't maintain two branches, then let's stop doing it. otoh,
> > we can't do maintenance releases without a stable branch, so we'd
> > better think about it before giving up.
>
> I do follow your logic on a stable vs. unstable tree, and can see
> the benefit of having it.
>
> > I've offered to help, much more than I should bother with. I'll leave
> > it to other Alpha stakeholders to decide what they want. I should
> > point out that I offered to our RedHat contacts to try to marshall an
> > Alpha-ready build, but so far it's like herding cats.
>
> Yea, it has been like that with the Linux/Alpha port for some
> time, including other packages then pgsql alone. :( As for the other Alpha
> stakeholders, I have yet to hear from any of them at all in this
> disscussion and for a while in any discussion concerning pgsql and
> Linux/Alpha. Of course, every now and then, some Linux/Alpha user comes
> along and asks why we haven't moved anywhere with pgsql in the last so
> long, and gets mad with any answer I try and give them. My conclusion
> about Linux/Alpha is that lots of people want the power of the alpha
> processor, but don't want to help out and get rid of some of the lingering
> sharp edges. They want it to work right out of the box! That leaves things
> to a few of us die hards to get everything working, and most of them
> focus on more fundamental things, like gcc and glibc, and the applications
> end up getting the short end of the stick. Ok, I will get off my soap box
> here, back to the trenches....
>
> > And *really*, if we have 3.5MB of diffs, who are we kidding about
> > knowing where they all came from and what they are doing? Backpatching
> > or developing patches on a clean 6.5.1 release is the only thing to do
> > for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months
> > for RPMs.
>
> After this discussion and a few tests of my own, I think I had
> better change my position on this issue.
> First of all, today's snapshot with Uncle G's patches compiles and
> runs on Linux/Intel and Solaris/Sparc as well as they do without the
> patches on the same snapshot for the most part. Though the patches seem to
> break the random regression test on Linux/Intel. Also, today's snapshot
> (clean) will not compile on Solaris/Sparc, as there is an extra #endif in
> ./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
> So, this snapshot is in suspect, and it looks like the alpha
> patches are as well, at least as far as other platforms go.
> My vote would be go back and do a 'alpha' patch off of 6.5.1, and
> distribute that to the distribution people to get pgsql running on
> Linux/Alpha in the short time. Then, four months or so down the road when
> the next release target comes up, we plan to have a version of pgsql that
> will run on both Alpha and other platforms. That means Uncle G's patches
> need to be checked for what they do to the other platforms.
> This would get us a Alpha ready version of pgsql now (there has
> been enough delay as it is, we really don't want to wait any more), not
> put us out on the limb with a possibly unstable release of pgsql, and
> gives us time to get the alpha patches properly tested and integrated into
> the main source tree.
> As I see it, these are the following things that need to be added
> to 6.5.1 to make it alpha ready:
>
> * Uncle G's Alpha patches { which I have }.
> * Makefile conditionals for Linux/Alpha { which I can find with
> only moderate trouble }.
> * Bruce's alignment patches { which I do not have }.
>
> Bruce, if you could get me your alignment patches, then I will try and
> apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
> ready state. Then we give that patch to debian and RH developers, tell
> them to only apply it to thier alpha builds, and that we will have a
> universal source tree for all platforms (including alpha) in a few months.
> This is simular to what was done (might even still be done) for
> the Linux kernel itself. To compile a 2.0.x kernel for Linux/Alpha, one
> got the clean source, a set of alpha patches for the same rev level, and
> applied them to the clean source to generate an alpha ready kernel source
> tree.
> Is this a viable idea, or just another horrible kludge?
>
> > My $0.03 ;)
>
> Raising the ante here? :) Well, then this was my four cents!
>
> ----------------------------------------------------------------------------
> | "For to me to live is Christ, and to die is gain." |
> | --- Philippians 1:21 (KJV) |
> ----------------------------------------------------------------------------
> | Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
> ----------------------------------------------------------------------------
> | http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
> ----------------------------------------------------------------------------
>
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Yea, it has been like that with the Linux/Alpha port for some
> time, including other packages then pgsql alone. :( As for the other Alpha
> stakeholders, I have yet to hear from any of them at all in this
> disscussion and for a while in any discussion concerning pgsql and
> Linux/Alpha. Of course, every now and then, some Linux/Alpha user comes
> along and asks why we haven't moved anywhere with pgsql in the last so
> long, and gets mad with any answer I try and give them. My conclusion
> about Linux/Alpha is that lots of people want the power of the alpha
> processor, but don't want to help out and get rid of some of the lingering
> sharp edges. They want it to work right out of the box! That leaves things
> to a few of us die hards to get everything working, and most of them
> focus on more fundamental things, like gcc and glibc, and the applications
> end up getting the short end of the stick. Ok, I will get off my soap box
> here, back to the trenches....
Yes, this is our impression too. We get lots of head-shaking, but not
lots of roll-up-their sleves help.
> First of all, today's snapshot with Uncle G's patches compiles and
> runs on Linux/Intel and Solaris/Sparc as well as they do without the
> patches on the same snapshot for the most part. Though the patches seem to
> break the random regression test on Linux/Intel. Also, today's snapshot
> (clean) will not compile on Solaris/Sparc, as there is an extra #endif in
> ./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
Fixed now. That was me. That file was a mess before.
> So, this snapshot is in suspect, and it looks like the alpha
> patches are as well, at least as far as other platforms go.
> My vote would be go back and do a 'alpha' patch off of 6.5.1, and
> distribute that to the distribution people to get pgsql running on
> Linux/Alpha in the short time. Then, four months or so down the road when
> the next release target comes up, we plan to have a version of pgsql that
> will run on both Alpha and other platforms. That means Uncle G's patches
> need to be checked for what they do to the other platforms.
Agreed.
> This would get us a Alpha ready version of pgsql now (there has
> been enough delay as it is, we really don't want to wait any more), not
> put us out on the limb with a possibly unstable release of pgsql, and
> gives us time to get the alpha patches properly tested and integrated into
> the main source tree.
> As I see it, these are the following things that need to be added
> to 6.5.1 to make it alpha ready:
>
> * Uncle G's Alpha patches { which I have }.
> * Makefile conditionals for Linux/Alpha { which I can find with
> only moderate trouble }.
> * Bruce's alignment patches { which I do not have }.
I just changed many DOUBLEALIGN's to MAXALIGN. It was a cosmetic fix,
as far as I could tell. Are they different on Alpha?
>
> Bruce, if you could get me your alignment patches, then I will try and
> apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
> ready state. Then we give that patch to debian and RH developers, tell
> them to only apply it to thier alpha builds, and that we will have a
> universal source tree for all platforms (including alpha) in a few months.
> This is simular to what was done (might even still be done) for
> the Linux kernel itself. To compile a 2.0.x kernel for Linux/Alpha, one
> got the clean source, a set of alpha patches for the same rev level, and
> applied them to the clean source to generate an alpha ready kernel source
> tree.
> Is this a viable idea, or just another horrible kludge?
Sounds good.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Thu, 29 Jul 1999, Bruce Momjian wrote:
> > * Uncle G's Alpha patches { which I have }.
> > * Makefile conditionals for Linux/Alpha { which I can find with
> > only moderate trouble }.
> > * Bruce's alignment patches { which I do not have }.
>
> I just changed many DOUBLEALIGN's to MAXALIGN. It was a cosmetic fix,
> as far as I could tell. Are they different on Alpha?
So, if I were to go through and make these changes in the -stable tree as
well, it would be purely cosmetic?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Thu, 29 Jul 1999, Bruce Momjian wrote:
>
> > > * Uncle G's Alpha patches { which I have }.
> > > * Makefile conditionals for Linux/Alpha { which I can find with
> > > only moderate trouble }.
> > > * Bruce's alignment patches { which I do not have }.
> >
> > I just changed many DOUBLEALIGN's to MAXALIGN. It was a cosmetic fix,
> > as far as I could tell. Are they different on Alpha?
>
> So, if I were to go through and make these changes in the -stable tree as
> well, it would be purely cosmetic?
>
I think so, but am not sure what the alpha has for those values.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > As I see it, these are the following things that need to be added
> > to 6.5.1 to make it alpha ready:
> > * Uncle G's Alpha patches { which I have }.
> > * Makefile conditionals for Linux/Alpha
> > * Bruce's alignment patches { which I do not have }.
> I just changed many DOUBLEALIGN's to MAXALIGN. It was a cosmetic fix,
> as far as I could tell. Are they different on Alpha?
> > Bruce, if you could get me your alignment patches, then I will try and
> > apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
> > ready state.
I *love* this plan. And I'll go one better: v6.5.x is not "dead", in
the sense that Tom Lane has been faithfully applying relevant patches
for his fixes in case a v6.5.2 is released. I'll guess that the Intel
problems noted with the main tree are not present in the v6.5.x tree,
so any new problems noted would be due to the upcoming Alpha patches.
Let's develop patches on 6.5.x (I'll post snapshots when we want them)
and Lamar and I can test the Intel behavior.
Unless someone else wants to do it, I'll handle applying the Alpha
patches to the v6.5.x branch of CVS.
We can publish an Alpha candidate tree so the debian folks can look at
it, and we can build a RPM for someone (Uncle George?) to test on a
RedHat box.
v6.5.2 might be possible yet ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On Fri, 30 Jul 1999, The Hermit Hacker wrote:
> I do not want to see any patches commit'd to v6.5.x branch that is
> *anything* but a minor bug fix...personally, we had a 2 month beta period
> on this...the Alpha related stuff should have been submit'd then, at the
> very latest...
Yea, they should have, but this is anything but a perfect world.
:(
> Please feel free to work at getting these into v6.6, *before* v6.6 is
> released, so that this problem doesn't rear its head again...
Will do! I will make an alpha patch for 6.5.1 to keep the alpha
people happy in the short term. Then I will work on evaluating the full
effect of the alpha patches and then integrate them into the main source
tree bit by bit until it all works on alpha, but does not adversly affect
any other platform. V6.6 is about four months out, right?
TTYL.
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
On Fri, 30 Jul 1999, Bruce Momjian wrote:
> > On Thu, 29 Jul 1999, Bruce Momjian wrote:
> >
> > > > * Uncle G's Alpha patches { which I have }.
> > > > * Makefile conditionals for Linux/Alpha { which I can find with
> > > > only moderate trouble }.
> > > > * Bruce's alignment patches { which I do not have }.
> > >
> > > I just changed many DOUBLEALIGN's to MAXALIGN. It was a cosmetic fix,
> > > as far as I could tell. Are they different on Alpha?
> >
> > So, if I were to go through and make these changes in the -stable tree as
> > well, it would be purely cosmetic?
> >
>
> I think so, but am not sure what the alpha has for those values.
It is only cosmetic, for on the alpha, after configure is run,
ALIGNOF_{LONG,DOUBLE,ALIGNOF} all equal '8'. Further testing showed that
the macros LONGALIGN, DOBULEALIGN, and MAXALIGN generate the same result
when provided with the same input value. Therefore, I don't see anyway
that changing DOUBLEALIGNs to MAXALIGNs would reduce unaligned traps on
the alpha. :(
PS. I am testing an alpha patched 6.5.1 right now, and so far it
looks promising. :) Final results soon!
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
On Thu, 29 Jul 1999, Bruce Momjian wrote:
> Yes, this is our impression too. We get lots of head-shaking, but not
> lots of roll-up-their sleves help.
That about sums things up very nicely... Even I am guilty of that
as I often find myself too busy to do anything more than tell someone that
pgsql is broken on alpha (not for much longer though), and yet never set
aside the time to do anything about it. :(
> > (clean) will not compile on Solaris/Sparc, as there is an extra #endif in
> > ./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
>
> Fixed now. That was me. That file was a mess before.
Interesitng that neither Linux/Alpha or Linux/Intel puked on it...
> > Bruce, if you could get me your alignment patches, then I will try and
> > apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
> > ready state. Then we give that patch to debian and RH developers, tell
> > them to only apply it to thier alpha builds, and that we will have a
> > universal source tree for all platforms (including alpha) in a few months.
> > This is simular to what was done (might even still be done) for
> > the Linux kernel itself. To compile a 2.0.x kernel for Linux/Alpha, one
> > got the clean source, a set of alpha patches for the same rev level, and
> > applied them to the clean source to generate an alpha ready kernel source
> > tree.
> > Is this a viable idea, or just another horrible kludge?
>
> Sounds good.
Ok, I have already started hacking up 6.5.1. It will take a little
while to run the regression tests and then I want to run a few pgsql
applications of mine through it as well to pound on it further. If I can't
break it, then I will release a patch soon. :)
Are there any other "alpha hacks" that I missed? TTYL.
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
On Fri, 30 Jul 1999, Thomas Lockhart wrote:
> > > As I see it, these are the following things that need to be added
> > > to 6.5.1 to make it alpha ready:
> > > * Uncle G's Alpha patches { which I have }.
> > > * Makefile conditionals for Linux/Alpha
> > > * Bruce's alignment patches { which I do not have }.
> > > Bruce, if you could get me your alignment patches, then I will try and
> > > apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
> > > ready state.
>
> I *love* this plan.
Great!
> And I'll go one better: v6.5.x is not "dead", in the sense that Tom
> Lane has been faithfully applying relevant patches for his fixes in
> case a v6.5.2 is released. I'll guess that the Intel problems noted
> with the main tree are not present in the v6.5.x tree, so any new
> problems noted would be due to the upcoming Alpha patches.
So, if I understand this correctly, the snapshot available on the
FTP site is from the unstable tree, and there is a "stable 6.5.x" tree
that can only be access by cvs{up}? And that this stable tree should not
have quite as much delta from 6.5.1 as the snapshots do? Or did I miss
something?
> Let's develop patches on 6.5.x (I'll post snapshots when we want them)
> and Lamar and I can test the Intel behavior.
Ok, patches are in progress. Regression tests passed, now pounding
on it with some of my own applications.
> We can publish an Alpha candidate tree so the debian folks can look at
> it, and we can build a RPM for someone (Uncle George?) to test on a
> RedHat box.
Sounds good.
> v6.5.2 might be possible yet ;)
Hmm... I don't think other people want to roll in the alpha
patches into the stable tree (with good reason). I think we are best off
with just an alpha only version of pgsql via patches on 6.5.1, and leave
integration of the alpha patches into the full pgsql source tree for 6.6.
My two cents.
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> writes:
>>>> (clean) will not compile on Solaris/Sparc, as there is an extra #endif in
>>>> ./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
>>
>> Fixed now. That was me. That file was a mess before.
> Interesitng that neither Linux/Alpha or Linux/Intel puked on it...
isinf.c doesn't get compiled at all on platforms that have native
isinf(), so the error wouldn't show up except on a platform that has
both a compiler that objects to extra #endif and no isinf().
I wouldn't be surprised if there are similar glitches in other files
under port/ :-(
> Ok, I have already started hacking up 6.5.1. It will take a little
> while to run the regression tests and then I want to run a few pgsql
> applications of mine through it as well to pound on it further. If I can't
> break it, then I will release a patch soon. :)
> Are there any other "alpha hacks" that I missed? TTYL.
You should be working from a CVS pull of the REL6_5_PATCHES branch,
not from the 6.5.1 distribution tarball --- I've committed several
fixes into that branch since 6.5.1, and I think other people have too.
(If that *is* what you're doing, then nevermind...)
regards, tom lane
> > Fixed now. That was me. That file was a mess before. > > Interesitng that neither Linux/Alpha or Linux/Intel puked on it... They probably don't use it. > Ok, I have already started hacking up 6.5.1. It will take a little > while to run the regression tests and then I want to run a few pgsql > applications of mine through it as well to pound on it further. If I can't > break it, then I will release a patch soon. :) > Are there any other "alpha hacks" that I missed? TTYL. No. The test for CPU in the Makefiles was so we could do -O2 in the general makefile, and just add some flags in the makefiles that caused problems. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > And I'll go one better: v6.5.x is not "dead", in the sense that Tom
> > Lane has been faithfully applying relevant patches for his fixes in
> > case a v6.5.2 is released. I'll guess that the Intel problems noted
> > with the main tree are not present in the v6.5.x tree, so any new
> > problems noted would be due to the upcoming Alpha patches.
>
> So, if I understand this correctly, the snapshot available on the
> FTP site is from the unstable tree, and there is a "stable 6.5.x" tree
> that can only be access by cvs{up}? And that this stable tree should not
> have quite as much delta from 6.5.1 as the snapshots do? Or did I miss
> something?
Yes. This is correct.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Fri, 30 Jul 1999, Ryan Kirkpatrick wrote:
> So, if I understand this correctly, the snapshot available on the
> FTP site is from the unstable tree, and there is a "stable 6.5.x" tree
> that can only be access by cvs{up}? And that this stable tree should not
> have quite as much delta from 6.5.1 as the snapshots do? Or did I miss
> something?
this is correct...
> Hmm... I don't think other people want to roll in the alpha
> patches into the stable tree (with good reason). I think we are best off
> with just an alpha only version of pgsql via patches on 6.5.1, and leave
> integration of the alpha patches into the full pgsql source tree for 6.6.
> My two cents.
We are going to be rolling a v6.5.2, and .3, and .4 ... basically, until
v6.6 is released, v6.5.x is our stable release, and, from a commercial
perspective, has to be maintained.
I don't expect anyone working on -current to maintain it, I'm going to
work on it, but I do hope that if someone fixes a bug in -current that
exists in -stable, and that can be *easily* fixed, that we get the fix in
there also...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Re: Stable vs Current (Was: Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha)
From
Ryan Kirkpatrick
Date:
On Fri, 30 Jul 1999, The Hermit Hacker wrote:
> On Fri, 30 Jul 1999, Ryan Kirkpatrick wrote:
> > Hmm... I don't think other people want to roll in the alpha
> > patches into the stable tree (with good reason). I think we are best off
> > with just an alpha only version of pgsql via patches on 6.5.1, and leave
> > integration of the alpha patches into the full pgsql source tree for 6.6.
> > My two cents.
>
> We are going to be rolling a v6.5.2, and .3, and .4 ... basically, until
> v6.6 is released, v6.5.x is our stable release, and, from a commercial
> perspective, has to be maintained.
I understand that. It is just that from what time I have spent
looking at the alpha patches, they do a lot more than just "maintenance".
So while there may indeed by 6.5.2, .3, etc.. releases, none of them
should include the alpha patches in the source tree (instead have a new
set of "after release" alpha specific patches, or stick them in contrib).
I don't want to put the alpha patches in until after I have a chance to
review them (for compatiblity to other platforms), which will probably
take a few weeks to a few months.
> I don't expect anyone working on -current to maintain it, I'm going to
> work on it, but I do hope that if someone fixes a bug in -current that
> exists in -stable, and that can be *easily* fixed, that we get the fix in
> there also...
Sounds good... Only the alpha fixes don't fall under the heading
of "*easily* fixed in -stable", so they ought to stay out of there for
now.
Otherwise your seperation of stable from current trees is a good
idea, and I now have a better understanding of development and release of
pgsql, especially in relation to the alpha patches. Thanks.
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
On Fri, 30 Jul 1999, Tom Lane wrote:
> Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> writes:
>
> > Ok, I have already started hacking up 6.5.1. It will take a little
> > while to run the regression tests and then I want to run a few pgsql
> > applications of mine through it as well to pound on it further. If I can't
> > break it, then I will release a patch soon. :)
> > Are there any other "alpha hacks" that I missed? TTYL.
>
> You should be working from a CVS pull of the REL6_5_PATCHES branch,
> not from the 6.5.1 distribution tarball --- I've committed several
> fixes into that branch since 6.5.1, and I think other people have too.
> (If that *is* what you're doing, then nevermind...)
Actually, I am working with the 6.5.1 tarball, for the simple
reason that I want a set of patches I can post on the debian-alpha mailing
list, along with the instructions to grab the 6.5.1 tarball from
ftp.postgresql.org, apply patches, configure, compile, install, and they
are set to go (No need to do a CVS pull, etc). Once this set of patches is
done and out, then I will do a cvs pull of the REL6_5_PATCHES branch and
make modifcations to my patch as needed so when 6.5.2 is released at some
later date, there is a minimal amount of work on my part to release new
alpha patches for that release.
That at least they easiest way I can see to do things for the near
term. For each 6.5.x release made, I make a set of patches that can be
applied to the release tar-ball, to make it alpha friendly. Then, only
when 6.6 comes along, will the alpha patches be intergrated into the main
tree, and the extra, "after-release-alpha-patches" will no longer be
needed. A little bit of extra work, but it has only taken me less than 2.5
hours this morning to backport the alpha patches from the most recent
snapshot to 6.5.1 tarball, so not a big deal.
Anyway, patches will be appearing shortly.
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
Re: Stable vs Current (Was: Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha)
From
The Hermit Hacker
Date:
On Fri, 30 Jul 1999, Ryan Kirkpatrick wrote:
> Sounds good... Only the alpha fixes don't fall under the heading
> of "*easily* fixed in -stable", so they ought to stay out of there for
> now.
If there are even pieces of the alpha patches that can be applied to the
central repository, please submit them for inclusion...#ifdef __alpha__
works quite well :) Reducing the size of the patch for each release is
always a good thing...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Re: Stable vs Current (Was: Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha)
From
Ryan Kirkpatrick
Date:
On Fri, 30 Jul 1999, The Hermit Hacker wrote:
> On Fri, 30 Jul 1999, Ryan Kirkpatrick wrote:
>
> > Sounds good... Only the alpha fixes don't fall under the heading
> > of "*easily* fixed in -stable", so they ought to stay out of there for
> > now.
>
> If there are even pieces of the alpha patches that can be applied to the
> central repository, please submit them for inclusion...#ifdef __alpha__
> works quite well :) Reducing the size of the patch for each release is
> always a good thing...
That is what I plan to do in the coming months as I review the
alpha patches chagne by change. And yes, #ifdefs are always good to use!
:)
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
Ryan Kirkpatrick wrote:
...
> Actually, I am working with the 6.5.1 tarball, for the simple
>reason that I want a set of patches I can post on the debian-alpha mailing
>list, along with the instructions to grab the 6.5.1 tarball from
>ftp.postgresql.org, apply patches, configure, compile, install, and they
>are set to go (No need to do a CVS pull, etc).
Hi Ryan,
I'm at a disadvantage here, because I don't have an Alpha and rely on
others on debian-alpha to get postgresql packages compiled for Alpha.
Thanks for your efforts on this.
I just want to comment on what you are saying about generating a Debian
source package. There will be a problem, because you are proposing to
provide source that will be different from the main 6.5.1 source; however,
the Debian archive assumes that source is identical across all architectures.
This means that the Alpha source for PostgreSQL must not be uploaded to the
Debian archive because it will replace the source for all other
architectures.
If this were to be a permanent problem, it could be addressed by renaming
the packages; however, this would cause a lot of trouble to many users,
so I don't want to do that when 6.6 will remove the need for it.
What I propose to do is to disable the Alpha build in the next version of
the Debian package (6.5.1-4) and make it put out information that the
Alpha source must be downloaded from <somewhere>. I would prefer that to be
in my account at www.debian.org, so that I can incorporate any changes
that go into the mainstream package.
As to producing the Alpha packages, the procedure should go something
like this:
1. Patch postgresql-6.5.1.orig (i.e. postgresql as provided at ftp.postgresql.org).
2. Examine the patches in the latest debian postgresql-6.5.1-x.diff.gz
(where x is the latest Debian release) and merge everything that does
not conflict with the new Alpha patches.
3. Update the version number in debian/changelog to 6.5.1-x.0.1alph and
build the binary packages.
4. Upload the binary packages only.
5. Put the source package in my account (and make sure I have permission
to write it!).
--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"And Samuel said, Hath the LORD as great delight in
burnt offerings and sacrifices, as in obeying the
voice of the LORD? Behold, to obey is better than
sacrifice, and to hearken than the fat of rams."
I Samuel 15:22
On Fri, 30 Jul 1999, Oliver Elphick wrote: > If this were to be a permanent problem, it could be addressed by renaming > the packages; however, this would cause a lot of trouble to many users, > so I don't want to do that when 6.6 will remove the need for it. > > What I propose to do is to disable the Alpha build in the next version of > the Debian package (6.5.1-4) and make it put out information that the > Alpha source must be downloaded from <somewhere>. I would prefer that to be > in my account at www.debian.org, so that I can incorporate any changes > that go into the mainstream package. What kind of patches are we dealing with? One of us could probably easily review them here and find a way to have the source patched in the event of an Alpha build environment (I already am working on a similar solution for binutils). Being pretty familiar with the postgresql source and the Alpha problems with it, feel free to mail me any patches that you want me to test (right now, I run postgresql, but have no data being served by it, so nothing's in danger). C
On Fri, 30 Jul 1999, Oliver Elphick wrote:
> Ryan Kirkpatrick wrote:
> ...
> > Actually, I am working with the 6.5.1 tarball, for the simple
> >reason that I want a set of patches I can post on the debian-alpha mailing
> >list, along with the instructions to grab the 6.5.1 tarball from
> >ftp.postgresql.org, apply patches, configure, compile, install, and they
> >are set to go (No need to do a CVS pull, etc).
>
> Hi Ryan,
> I'm at a disadvantage here, because I don't have an Alpha and rely on
> others on debian-alpha to get postgresql packages compiled for Alpha.
> Thanks for your efforts on this.
You are welcome. :)
> I just want to comment on what you are saying about generating a Debian
> source package. There will be a problem, because you are proposing to
> provide source that will be different from the main 6.5.1 source; however,
> the Debian archive assumes that source is identical across all architectures.
> This means that the Alpha source for PostgreSQL must not be uploaded to the
> Debian archive because it will replace the source for all other
> architectures.
I am well aware of this, and if I could have avoided it, I would
have. But I decided that the ablity of getting pgsql working on
linux/alpha today out weighted any transient difficulties in packaging
(that would vanish with 6.6 in a couple of months). If you think it was a
bad decision, the fault then is mine. I have been trying for 2-3 years to
get pgsql running right on linux/alpha, and don't want to hold up the best
solution we have had (ever) for another few months. That at least is the
reasons behind my actions.
> As to producing the Alpha packages, the procedure should go something
> like this:
>
> 1. Patch postgresql-6.5.1.orig (i.e. postgresql as provided at ftp.postgresql.org).
>
> 2. Examine the patches in the latest debian postgresql-6.5.1-x.diff.gz
> (where x is the latest Debian release) and merge everything that does
> not conflict with the new Alpha patches.
>
> 3. Update the version number in debian/changelog to 6.5.1-x.0.1alph and
> build the binary packages.
>
> 4. Upload the binary packages only.
>
> 5. Put the source package in my account (and make sure I have permission
> to write it!).
Ok, this I can do. It will take me about a week to get it all
done, but it does appear to be do-able. Most of the debian patches for
pgsql should apply from what I have heard (from debian-alpha people),
except for the palloc one, if memory serves me right. Either way, I should
be able to work through them given some time.
The only tricky parts are the actual uploads of the binaries and
source code... I am not a Debian developer (maybe someday, when I have
more time), and unless there is an anonymous access to the locations you
list above, I will not be able to upload them. Either provide more details
on the uploading, or I will just put both on my web site, and you can grab
them from there and put them where needed.
TTYL.
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
On Fri, 30 Jul 1999, Christopher C Chimelis wrote:
> What kind of patches are we dealing with? One of us could probably easily
> review them here and find a way to have the source patched in the event of
> an Alpha build environment (I already am working on a similar solution for
> binutils). Being pretty familiar with the postgresql source and the Alpha
> problems with it, feel free to mail me any patches that you want me to
> test (right now, I run postgresql, but have no data being served by it, so
> nothing's in danger).
The patches are only about 60k, and apply cleanly to the 6.5.1
tarball. Once applied, pgsql will compile as per usual (as stated in the
INSTALL file). So, if you can put some conditional in the pgsql package
build to apply my patch (singular) when doing a compile on alpha, that
would be great.
If this is what you want to do, let me know, and I will not try
and generate a pgsql alpha deb myself (as Oliver asked in his email). This
will save me time and allow me to move on to actually processing the alpha
patches for the 6.6 pgsql tree.
TTYL.
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
> > I just want to comment on what you are saying about generating a Debian
> > source package. There will be a problem, because you are proposing to
> > provide source that will be different from the main 6.5.1 source; however,
> > the Debian archive assumes that source is identical across all architectures.
The RH RPM distribution has the same constraints. I have hopes that I
can take the v6.5.1 tarball, Ryan's patches, a test on RH Alpha, and
then validate them for the i386 (and sparc, with a volunteer tester)
architectures. If that flys, then perhaps we should commit to a v6.5.2
which *does* contain these changes, but imho we should postpone the
discussion of that until we have shown exactly what it takes.
If validating on i386 succeeds, we can also do a v6.5.1+patches build
of an RPM, and presumably the Debian packaging could work this way
too. So it doesn't absolutely require a commit back to the Postgres
cvs branch if we don't have a consensus on that.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Ryan Kirkpatrick wrote:
...
> If this is what you want to do, let me know, and I will not try
>and generate a pgsql alpha deb myself (as Oliver asked in his email). This
>will save me time and allow me to move on to actually processing the alpha
>patches for the 6.6 pgsql tree.
Sorry Ryan; I had not meant that _you_ should be generating the Debian
package! I was just documenting the process.
--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Have not I commanded thee? Be strong and of a good
courage; be not afraid, neither be thou dismayed; for
the LORD thy God is with thee whithersoever thou
goest." Joshua 1:9
On Sat, 31 Jul 1999, Oliver Elphick wrote:
> Ryan Kirkpatrick wrote:
> ...
> > If this is what you want to do, let me know, and I will not try
> >and generate a pgsql alpha deb myself (as Oliver asked in his email). This
> >will save me time and allow me to move on to actually processing the alpha
> >patches for the 6.6 pgsql tree.
>
> Sorry Ryan; I had not meant that _you_ should be generating the Debian
> package! I was just documenting the process.
After reading other people's responses to your email, I figured
that out. But the email was addressed to me, and only CCed to others,
so it was a bit confusing at first. :) If I can be of any help though
in gettting the alpha Pgsql deps made, (testing out debs, etc...), feel
free to ask.
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------