that's quite a release! thanks to everyone who contributed. i really like this list of packaged dependencies, that makes it very simple to see what's inside. wrote: -- Thank you, James Bayer

I would imagine you could bind a service to a route any time you want to customize incoming traffic in some way. But that customization wouldn't necessarily have to be implemented as a proxy. Here

Hi everyone, The Buildpacks team just cut a series of releases removing lucid64 binaries from the buildpacks. *Background* As announced earlier this year, the lucid64 stack ("rootfs") reached End

Initially we're targeting support for one service per route, and create-route/update-route accomplishes this simply. Associating multiple services with a route isn't as simple as binding an app as

wrote: Fair point, and thank you for the use case. Brokers have the option of declaring whether a service is bindable or not in order to provide a better user experience when services are not

Interesting idea; I'll talk to Greg O about it. Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc.

This is interesting. Could you flesh this out for me? What use cases do you have in mind for associating a service instance with a route, but not providing a forwarding address? Good feedback.

There are ways to install .deb packages as a normal user, as exemplified by the following Heroku buildpack: (Please note that this buildpack will not work on CF without modifications.) You may want

I am sorry, but in order to run apt-get you need root privileges and you do not have them inside a Warden container of a DEA. Processes run as unprivileged user "vcap" who cannot gain root privileges

Hi all, I’m currently working on a project where I have my gem source in our local git enterprise server, and I need to push an app that uses it to an instance of CF (v208) that is disconnected

I'm pleased to announce the release of the java-buildpack, version 3.1. This release was focused on new monitoring frameworks and the Memory Calculator. The Memory Calculator removes the need to

Hi All, I am trying to create a custom build pack. To create a stack like WineHQ with some VS2010 C++ Runtime to run windows native services. BuildPack :- bin/compile #!/usr/bin/env bash echo

+1 for binding to a specific route (for all apps) instead of binding for all routes of an app. One use-case that this will enable is content-transformation service routers to only be applied on some

i'm not sure if this is the right property or not, maybe dieu knows: https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/spec#L65-L67 -- Thank you, James Bayer

*I agree that space isn't needed, but I don't think we can remove it from create-route until v7; that command already exists and space is a required argument. Seems like it would be a backwards

I am using DEA. But I didn’t found where the container was kept. Is it compressed and stored somewhere? I also took a look at /var/vcap/data/dea_next/crashes/id, it only contain the files in

I like the idea of binding to a route instead of an app. Much simpler conceptually when considering a route can be bound to multiple apps. I'm excited to eventually bind services to more CF entities

Hi James, All good suggestions; responses inline. As we're still quite a ways from CLI work, and the proposed change is somewhat fundamental, I'm primarily interested in determining whether anyone

Apologies for the delayed release notes. Currently travelling in the UK. So sunny! ----- The cf-release v212 was released on June 22nd, 2015 - IMPORTANT: Database migrations have been moved

Thanks for the update to [1], this really helps to have access to slides speakers shared. Regards, Guillaume. [1] http://www.cfsummit.com/program/slides wrote: