Re: Problem with OpenSCG downloads

Jim Mlodgenski <jimm@postgresconf.org>

From: Jim Mlodgenski <jimm@postgresconf.org>
To: Dave Page <dpage@pgadmin.org>
Cc: Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@anarazel.de>, PostgreSQL www <pgsql-www@postgresql.org>, Denis Lussier <denisl@openscg.com>
Date: 2018-08-16T15:19:49Z
Lists: pgsql-hackers
On Thu, Aug 16, 2018 at 11:00 AM, Dave Page <dpage@pgadmin.org> wrote:

>
>
> On Thu, Aug 16, 2018 at 3:35 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
>> On Thu, Aug 16, 2018 at 06:00:30AM -0700, Andres Freund wrote:
>> > Random observation: http://www.openscg.com/bigsql/
>> postgresql/installers/
>> > seems to indicate that packages aren't updated anymore. While it says
>> > "(09-Aug-18)" besides the major versions, it does not actually in fact
>> > have the last set of minor releases.  I suspect that's related to
>> > openscg's acquisition by amazon?  Either they need to catch up, or we
>> > need to take down the page and probably alert people about that fact.
>>
>> Forwarding Andres's email above to www for research.
>>
>
> Jimbo assured me at PGCon that Amazon were going to ensure those packages
> were kept up to date in the normal schedule.
>
> Jim, do you know what's happening?
>
>

Yea, we are working on getting them out ASAP. Because of the acquisition,
our build servers are now sitting in physical locations where people don't
regularly work. In this particular case, they are sitting in our NJ office
which had a power outage long enough the the UPS drained requiring someone
to physically hit the button to power up the servers so we can do the
builds. We're working on moving the builds to this newfangled thing called
the cloud so we don't have the problem in the future. :-)

 I'll ask the team to give me an ETA and report back.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove test for VA_ARGS, implied by C99.

  2. Introduce minimal C99 usage to verify compiler support.

  3. Require C99 (and thus MSCV 2013 upwards).

  4. Require a C99-compliant snprintf(), and remove related workarounds.

  5. Try to enable C99 in configure, but do not rely on it (yet).

  6. Make snprintf.c follow the C99 standard for snprintf's result value.

  7. Clean up assorted misuses of snprintf()'s result value.