Horton
Menu

Re: Problem with OpenSCG downloads

Justin Clift <justin@postgresql.org>

View thread
From: Justin Clift <justin@postgresql.org>
To: PostgreSQL www <pgsql-www@postgresql.org>
Date: 2018-08-16T15:32:00Z
Lists: pgsql-hackers 
On 2018-08-16 16:25, Andres Freund wrote:
> Hi,
> 
> On 2018-08-16 11:19:49 -0400, Jim Mlodgenski wrote:
>> On Thu, Aug 16, 2018 at 11:00 AM, Dave Page <dpage@pgadmin.org> wrote:
>> > 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.
> 
> FWIW, I find this pretty damning given that there's been new security
> release for a week: You've added no notes about it to the bigsql
> download page. Pinged nobody, to get the downloadlinks temporarily
> adorned with a warning on the pg site. And then there's the issue that
> the dates besides the releases on the download page are referencing the
> date of the newest set of minor releases, but aren't actually new.
> 
> This is ridiculously intransparent.

Is it fairly simple for us to just comment out/remove the links for now?

We don't want to be pointing people to software with known security 
issues.

We can put the links back in when the updated downloads are in place. :)

+ Justin

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.