Thread
-
Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha
Oliver Elphick <olly@lfix.co.uk> — 1999-07-30T22:53:59Z
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 -
Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha
Christopher C Chimelis <chris@beezer.med.miami.edu> — 1999-07-31T00:52:04Z
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
-
Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-31T02:30:57Z
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/ | ----------------------------------------------------------------------------
-
Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-31T02:34:52Z
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/ | ----------------------------------------------------------------------------
-
Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-07-31T02:54:05Z
> > 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