Re: [HACKERS] buildfarm breakage
Zdenek Kotala wrote: Andrew Dunstan p??e v po 08. 02. 2010 v 20:07 -0500: Our Solaris *moth members seem to have stopped building. Have we lost them? Hi Andrew, The answer is not simple. Yes, we lost Solaris 8 and 9 machines which was reinstalled and now they are used for different purpose. It was planned before the April and I announced it long time ago. It unfortunately happed and timing looks strange. And I did not find replacement. I have replacement for nevada/x86 machine already, but I need to setup it which is one item in my very long TODO list :(. Solaris 10 Sparc/x86 and nevada sparc are covered at this moment. I think we have to accept the inevitable result that Postgres support on Solaris is going to diminish over time. We certainly are going to get less support from Sun/Oracle, and one day the use of Postgres might even be obstructed on Solaris or void software support contracts. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
Andrew Dunstan píše v po 08. 02. 2010 v 20:07 -0500: Our Solaris *moth members seem to have stopped building. Have we lost them? Hi Andrew, The answer is not simple. Yes, we lost Solaris 8 and 9 machines which was reinstalled and now they are used for different purpose. It was planned before the April and I announced it long time ago. It unfortunately happed and timing looks strange. And I did not find replacement. I have replacement for nevada/x86 machine already, but I need to setup it which is one item in my very long TODO list :(. Solaris 10 Sparc/x86 and nevada sparc are covered at this moment. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
2010/2/9 Magnus Hagander mag...@hagander.net: On Tue, Feb 9, 2010 at 17:11, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: Here's a patch that fixes this. I put it locally for the radius authentication for now, since we don't use this anywhere else. Should we put this in /port/ somewhere, or is this good for now? How about dropping it in src/backend/port/win32/mingwcompat.c ? Oh, meh. I had forgotten we had that file :-) Thanks for the reminder, will verify tonight that it still works after I do that. If someone didn't notice, I have applied that fix and it appears to have solved it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
Magnus Hagander mag...@hagander.net writes: If someone didn't notice, I have applied that fix and it appears to have solved it. ... and there was much rejoicing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
On Mon, Feb 08, 2010 at 08:20:04PM -0500, Tom Lane wrote: MSVC builds are broken from a missing _isnan function on the ECPG tests. Do we need to link in a math lib or something there? It looks to me like the problem is that that test is being compiled without benefit of any platform-dependent code whatsoever. In the rest of the system, isnan and isinf work on WIN32 because the compiles can see the macro definitions in port/win32.h. nan_test is apparently not including that. I'm not sure of Michael's plan for portability of these test cases --- if he doesn't want to include c.h or something close to that, I think the nan test has to go away. Actually I was hoping someone with some Windows experience would take a look at it or Zoltan would come up with a fix, after all it was his addition. :-) Looking at the portability header file it appears that isnan/isinf are only one line defines, so it doesn't look like a major problem adding these. I will try fixing this, but bear with me as I have to use the buildfarm for testing. I don't have a Windows build environment. If someone is willing to run a test on Windows for me, please tell me. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
On Tue, Feb 9, 2010 at 9:39 AM, Michael Meskes mes...@postgresql.org wrote: Actually I was hoping someone with some Windows experience would take a look at it or Zoltan would come up with a fix, after all it was his addition. :-) Looking at the portability header file it appears that isnan/isinf are only one line defines, so it doesn't look like a major problem adding these. I will try fixing this, but bear with me as I have to use the buildfarm for testing. I don't have a Windows build environment. If you feel inclined, you can always use Amazon EC2 for Win32 testing: http://blog.hagander.net/archives/151-Testing-PostgreSQL-patches-on-Windows-using-Amazon-EC2.html -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
On Tuesday, February 9, 2010, Dave Page dp...@pgadmin.org wrote: On Tue, Feb 9, 2010 at 9:39 AM, Michael Meskes mes...@postgresql.org wrote: Actually I was hoping someone with some Windows experience would take a look at it or Zoltan would come up with a fix, after all it was his addition. :-) Looking at the portability header file it appears that isnan/isinf are only one line defines, so it doesn't look like a major problem adding these. I will try fixing this, but bear with me as I have to use the buildfarm for testing. I don't have a Windows build environment. If you feel inclined, you can always use Amazon EC2 for Win32 testing: http://blog.hagander.net/archives/151-Testing-PostgreSQL-patches-on-Windows-using-Amazon-EC2.html I actually brok the image that post talks about. But contact me on IM if you want info about the new one I use andbhavent gotten around to post abou yet. /Magnus -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
Michael Meskes írta: On Mon, Feb 08, 2010 at 08:20:04PM -0500, Tom Lane wrote: MSVC builds are broken from a missing _isnan function on the ECPG tests. Do we need to link in a math lib or something there? It looks to me like the problem is that that test is being compiled without benefit of any platform-dependent code whatsoever. In the rest of the system, isnan and isinf work on WIN32 because the compiles can see the macro definitions in port/win32.h. nan_test is apparently not including that. I'm not sure of Michael's plan for portability of these test cases --- if he doesn't want to include c.h or something close to that, I think the nan test has to go away. Actually I was hoping someone with some Windows experience would take a look at it or Zoltan would come up with a fix, after all it was his addition. :-) Yes, it was. :-) For the regression test, I am inclined to just do #ifdef WIN32 #define isnan(x) _isnan(x) #define isinf(x) _isinf(x) #endif or something like that in the regression test only. MSVC seems to define the these functions with an underscore prefix. :-( Can we try that? Without adding port/* to libpq, this is the smallest change that may fix the Windows regression tests. Looking at the portability header file it appears that isnan/isinf are only one line defines, so it doesn't look like a major problem adding these. I will try fixing this, but bear with me as I have to use the buildfarm for testing. I don't have a Windows build environment. If someone is willing to run a test on Windows for me, please tell me. Michael -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
For the regression test, I am inclined to just do #ifdef WIN32 #define isnan(x) _isnan(x) #define isinf(x) _isinf(x) #endif Well the isinf() macro is different in win32.h. I did make a change and apparently red_bat is now green again. Hopefully that was it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
On Tue, Feb 9, 2010 at 02:20, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a recent RADIUS support fix. Looks like we might need to include win32.h in there. That was discussed already. I assume Magnus is going to address it as soon as he gets back from FOSDEM. Yes. It's not quite that simple, though. It *is* in the win32 header for mingw. As an extern. But it's not present in the libraries on mingw (it *is* present on msvc). So we need to define the actual contents of it. I'll look at getting a mingw box up to fix that as soon as possible, hopefully today. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
On Tue, Feb 9, 2010 at 13:52, Magnus Hagander mag...@hagander.net wrote: On Tue, Feb 9, 2010 at 02:20, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a recent RADIUS support fix. Looks like we might need to include win32.h in there. That was discussed already. I assume Magnus is going to address it as soon as he gets back from FOSDEM. Yes. It's not quite that simple, though. It *is* in the win32 header for mingw. As an extern. But it's not present in the libraries on mingw (it *is* present on msvc). So we need to define the actual contents of it. I'll look at getting a mingw box up to fix that as soon as possible, hopefully today. Here's a patch that fixes this. I put it locally for the radius authentication for now, since we don't use this anywhere else. Should we put this in /port/ somewhere, or is this good for now? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ mingw_ipv6.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
Magnus Hagander mag...@hagander.net writes: Here's a patch that fixes this. I put it locally for the radius authentication for now, since we don't use this anywhere else. Should we put this in /port/ somewhere, or is this good for now? How about dropping it in src/backend/port/win32/mingwcompat.c ? The advantage of putting it in src/port/ is that it would possibly help client-side code sometime in future. But what seems more likely to happen is that the mingw people will fix their oversight, and then we'd be risking link conflicts, which will be harder to fix on the client side. So I'm inclined to not go there as long as we don't actually need it on client side. But putting mingw hacks in a mingw-specific place seems a good idea. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
On Tue, Feb 9, 2010 at 17:11, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: Here's a patch that fixes this. I put it locally for the radius authentication for now, since we don't use this anywhere else. Should we put this in /port/ somewhere, or is this good for now? How about dropping it in src/backend/port/win32/mingwcompat.c ? Oh, meh. I had forgotten we had that file :-) Thanks for the reminder, will verify tonight that it still works after I do that. The advantage of putting it in src/port/ is that it would possibly help client-side code sometime in future. But what seems more likely to happen is that the mingw people will fix their oversight, and then we'd be risking link conflicts, which will be harder to fix on the client side. So I'm inclined to not go there as long as we don't actually need it on client side. But putting mingw hacks in a mingw-specific place seems a good idea. yeah, agreed. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
Andrew Dunstan and...@dunslane.net writes: Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a recent RADIUS support fix. Looks like we might need to include win32.h in there. That was discussed already. I assume Magnus is going to address it as soon as he gets back from FOSDEM. MSVC builds are broken from a missing _isnan function on the ECPG tests. Do we need to link in a math lib or something there? It looks to me like the problem is that that test is being compiled without benefit of any platform-dependent code whatsoever. In the rest of the system, isnan and isinf work on WIN32 because the compiles can see the macro definitions in port/win32.h. nan_test is apparently not including that. I'm not sure of Michael's plan for portability of these test cases --- if he doesn't want to include c.h or something close to that, I think the nan test has to go away. Our Solaris *moth members seem to have stopped building. Have we lost them? They're not *all* dead, but it sure looks like Oracle scaled that lab way back the moment they owned it. I'm surprised any of them are still alive :-( regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] buildfarm breakage
On Mon, Feb 8, 2010 at 5:20 PM, Tom Lane t...@sss.pgh.pa.us wrote: Our Solaris *moth members seem to have stopped building. Have we lost them? They're not *all* dead, but it sure looks like Oracle scaled that lab way back the moment they owned it. I'm surprised any of them are still alive :-( We still have a T2000 system with solaris on it. It was not in the buildfarm because it was felt this configuration was already covered. Let me know if we want to set it up for the buildfarm. Regards, Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
