It's not just the Precise packages that are missing. The complete Debian 
suite is missing too, squeeze, wheezy, jessy and sid.

On Tuesday, 1 October 2013 04:59:16 UTC+2, blkperl wrote:
>
> No packages for precise/raring? Its missing debs for 1.5.0. Lucid seems 
> fine
>
> Thanks,
> William
>
>
> On Mon, Sep 30, 2013 at 4:56 PM, Chris Price 
> <ch...@puppetlabs.com<javascript:>
> > wrote:
>
>> PuppetDB 1.5.0 is now available for download!  This is a new feature 
>> release that contains a few bug-fixes as well.
>>
>> ============= 
>> ## Downloads ## 
>> ============= 
>>
>> Available in native package format at: 
>> http://yum.puppetlabs.com and http://apt.puppetlabs.com 
>>
>> Puppet module: 
>> http://forge.puppetlabs.com/puppetlabs/puppetdb 
>>
>> Source (same license as Puppet): http://github.com/puppetlabs/puppetdb/ 
>>
>> # Documentation (including how to install): 
>> http://docs.puppetlabs.com/puppetdb/1.<http://docs.puppetlabs.com/puppetdb/1.2>
>> 5
>>
>> # Issues can be filed at: 
>> http://projects.puppetlabs.com/projects/puppetdb/issues 
>>
>>
>> ============================ 
>> ##  PuppetDB 1.5.0 Release Notes  ## 
>> ============================ 
>>
>> Notable features and improvements:
>>
>> * (#21520) Configuration for soft failure when PuppetDB is unavailable
>>
>>   This feature adds a new option 'soft_write_failure' to the puppetdb
>>   configuration.  If enabled the terminus behavior is changed so that if a
>>   command or write fails, instead of throwing an exception and causing 
>> the agent
>>   to stop it will simply log an error to the puppet master log.
>>
>> * New v3 query API
>>
>>   New `/v3` URLs are available for all query endpoints.  The `reports` and
>>   `events` endpoints, which were previously considered `experimental`, 
>> have
>>   been moved into `/v3`.  Most of the other endpoints are 100% 
>> backwards-compatible
>>   with `/v2`, but now offer additional functionality.  There are few minor
>>   backwards-incompatible changes, detailed in the comments about 
>> individual
>>   endpoints below.
>>
>> * Query paging
>>
>>   This feature adds a set of new HTTP query parameters that can be used 
>> with most
>>   of the query endpoints (`fact_names`, `facts`, `resources`, `nodes`, 
>> `events`,
>>   `reports`, `event-counts`) to allow paging through large result sets 
>> over
>>   multiple queries.  The available HTTP query parameters are:
>>
>>      * `limit`: an integer specifying the maximum number of results to
>>         return.
>>      * `order-by`: a list of fields to sort by, in ascending or 
>> descending order.
>>         The legal set of fields varies by endpoint; see the documentation 
>> for
>>         individual endpoints for more info.
>>      * `offset`: an integer specifying the first result in the result set 
>> that
>>         should be returned.  This can be used in combination with `limit`
>>         and `order-by` to page through a result set over multiple queries.
>>      * `include-total`: a boolean flag which, if set, will cause the HTTP 
>> response
>>        to contain an `X-Records` header indicating the total number of 
>> results that are
>>        available that match the query.  (Mainly useful in combination 
>> with `limit`.)
>>
>> * New features available on `events` endpoint
>>
>>     * The `events` data now contains `file` and `line` fields.  These 
>> indicate
>>       the location in the manifests where the resource was declared. 
>>  They can
>>       be used as input to an `events` query.
>>     * Add new `configuration-version` field, which contains the value 
>> that Puppet
>>       supplied during the agent run.
>>     * New `containing-class` field: if the resource is declared inside of 
>> a
>>       Puppet class, this field will contain the name of that class.
>>     * New `containment-path` field: this field is an array showing the 
>> full
>>       path to the resource from the root of the catalog (contains an 
>> ordered
>>       list of names of the classes/types that the resource is contained 
>> within).
>>     * New queryable timestamp fields:
>>         * `run-start-time`: the time (on the agent node) that the run 
>> began
>>         * `run-end-time`: the time (on the agent node) that the run 
>> completed
>>         * `report-receive-time`: the time (on the puppetdb node) that the 
>> report was received by PuppetDB
>>     * Restrict results to only include events that occurred in the latest 
>> report
>>       for a given node: `["=", "latest-report?", true]`
>>
>> * New `event-counts` endpoint
>>
>>     `v3` of the query API contains a new `event-counts` endpoint, which 
>> can be
>>     used to retrieve count data for an event query.  The basic input to 
>> the
>>     endpoint is an event query, just as you'd provide to the `events` 
>> endpoint,
>>     but rather than returning the actual events, this endpoint returns 
>> counts
>>     of `successes`, `failures`, `skips`, and `noops` for the events that 
>> match
>>     the query.  The counts may be aggregated on a per-resource, per-class,
>>     or per-node basis.
>>
>> * New `aggregate-event-counts` endpoint
>>
>>   This endpoint is similar to the `event-counts` endpoint, but rather than
>>   aggregating the counts on a per-node, per-resource, or per-class basis,
>>   it returns aggregate counts across your entire population.
>>
>> * New `server-time` endpoint
>>
>>   This endpoint simply returns a timestamp indicating the current time on
>>   the PuppetDB server.  This can be used as input to time-based queries
>>   against timestamp fields that are populated by PuppetDB.
>>
>> * Minor changes to `resources` endpoint for `v3`
>>
>>   The `sourcefile` and `sourceline` fields have been renamed to `file` 
>> and `line`,
>>   for consistency with other parts of the API.
>>
>> * Minor changes relating to reports storage and query
>>
>>   * `store report` command has been bumped up to version `2`.
>>   * Report data now includes a new `transaction-uuid` field; this is 
>> generated
>>     by Puppet (as of Puppet 3.3) and can be used to definitively 
>> correlate a report
>>     with the catalog that was used for the run.  This field is queryable 
>> on the
>>     `reports` endpoint.
>>   * Reports now support querying by the field `hash`; this allows you to 
>> retrieve
>>     data about a given report based on the report hash for an event 
>> returned
>>     by the `events` endpoint.
>>
>> * Minor changes relating to catalog storage
>>
>>   * `store catalog` command has been bumped to version `3`.
>>   * Catalog data now includes the new `transaction-uuid` field; see notes 
>> above.
>>
>> Bug fixes:
>>
>> * PuppetDB report processor was truncating microseconds from report 
>> timestamps;
>>   all timestamp fields should now retain full precision.
>>
>> * Record resource failures even if Puppet doesn't generate an event for 
>> them in the
>>   report: in rare cases, Puppet will generate a report that indicates a 
>> failure
>>   on a resource but doesn't actually provide a failure event.  Prior to 
>> PuppetDB
>>   1.5, the PuppetDB report processor was only checking for the existence 
>> of
>>   events, so these resources would not show up in the PuppetDB report. 
>>  This is
>>   really a bug in Puppet (which should be fixed as of Puppet 3.3), but 
>> the PuppetDB
>>   report processor is now smart enough to detect this case and synthesize 
>> a failure
>>   event for the resource, so that the failure is at least visible in the 
>> PuppetDB
>>   report data.
>>
>> * Filter out the well-known "Skipped Schedule" events: in versions of 
>> Puppet prior
>>   to 3.3, every single agent report would include six events whose status 
>> was
>>   `skipped` and whose resource type was `Schedule`.  (The titles were 
>> `never`,
>>   `puppet`, `hourly`, `daily`, `weekly`, and `monthly`.)  These events 
>> were not
>>   generally useful and caused a great deal of pollution in the PuppetDB 
>> database.
>>   They are no longer generated as of Puppet 3.3, but for compatibility 
>> with
>>   older versions of Puppet, the report terminus in PuppetDB 1.5 will 
>> filter
>>   these events out before storing the report in PuppetDB.
>>
>> * Log a message when a request is blocked due to the certificate 
>> whitelist:
>>   prior to 1.5, when a query or command was rejected due to PuppetDB's 
>> certificate
>>   whitelist configuration, there was no logging on the server that could 
>> be used
>>   to troubleshoot the cause of the rejection.  We now log a message, in 
>> hopes of
>>   making it easier for administrators to track down the cause of 
>> connectivity
>>   issues in this scenario.
>>
>> * (#22122) Better log messages when puppetdb-ssl-setup is run before 
>> Puppet
>>   certificates are available.
>>
>> * (#22159) Fix a bug relating to anonymizing catalog edges in exported 
>> PuppetDB
>>   data.
>>
>> * (#22168) Add ability to configure maximum number of threads for Jetty 
>> (having too
>>   low of a value for this setting on systems with large numbers of cores 
>> could
>>   prevent Jetty from handling requests).
>>
>>  
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-dev+...@googlegroups.com <javascript:>.
>> To post to this group, send email to puppe...@googlegroups.com<javascript:>
>> .
>> Visit this group at http://groups.google.com/group/puppet-dev.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> -- 
> Thanks,
> William
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to