Oh brother, I didn't even know about that. Yikes. I suspect it was Shane?

--Paul

> On Mar 18, 2015, at 2:41 PM, Chris McDonough <email address hidden> wrote:
> 
> I think I need some help from whomever created
> "pylibmc-1.1.1-agendaless1" to see if the patch applied in our forked
> version is still necessary for pylibmc-1.3.0:
> 
> Here's the patch:
> 
> [chrism@thinko pylibmc-1.1.1]$ diff -u -r . ~/projects/karl/karlhosting.github.com/pyramid/production/pylibmc-1.1.1-agendaless1/
> diff -u -r ./PKG-INFO /home/chrism/projects/karl/karlhosting.github.com/pyramid/production/pylibmc-1.1.1-agendaless1/PKG-INFO
> --- ./PKG-INFO	2010-06-07 10:04:04.000000000 -0400
> +++ /home/chrism/projects/karl/karlhosting.github.com/pyramid/production/pylibmc-1.1.1-agendaless1/PKG-INFO	2011-04-06 16:20:58.000000000 -0400
> @@ -1,6 +1,6 @@
> Metadata-Version: 1.0
> Name: pylibmc
> -Version: 1.1.1
> +Version: 1.1.1-agendaless1
> Summary: Quick and small memcached client for Python
> Home-page: http://sendapatch.se/projects/pylibmc/
> Author: Ludvig Ericson
> diff -u -r ./_pylibmcmodule.c /home/chrism/projects/karl/karlhosting.github.com/pyramid/production/pylibmc-1.1.1-agendaless1/_pylibmcmodule.c
> --- ./_pylibmcmodule.c	2010-06-03 15:13:45.000000000 -0400
> +++ /home/chrism/projects/karl/karlhosting.github.com/pyramid/production/pylibmc-1.1.1-agendaless1/_pylibmcmodule.c	2011-04-06 16:48:29.000000000 -0400
> @@ -1054,6 +1054,7 @@
>      */
> 
>     memcached_return rc;
> +    *err_func = NULL;
> 
>     rc = memcached_mget(mc, (const char **)keys, key_lens, nkeys);
> 
> @@ -1075,9 +1076,10 @@
>         /* if loop spins out of control, this fails */
>         assert(nkeys >= (*nresults));
> 
> +        res->key_len = 0;
>         res->value = memcached_fetch(mc, res->key, &res->key_len,
>                                      &res->value_len, &res->flags, &rc);
> -        assert(res->value_len < MEMCACHED_MAX_KEY);
> +        assert(res->key_len < MEMCACHED_MAX_KEY);
> 
>         if (res->value == NULL || rc == MEMCACHED_END) {
>             /* This is how libmecached signals EOF. */
> diff -u -r ./pylibmc-version.h /home/chrism/projects/karl/karlhosting.github.com/pyramid/production/pylibmc-1.1.1-agendaless1/pylibmc-version.h
> --- ./pylibmc-version.h	2010-06-07 09:23:30.000000000 -0400
> +++ /home/chrism/projects/karl/karlhosting.github.com/pyramid/production/pylibmc-1.1.1-agendaless1/pylibmc-version.h	2011-04-06 16:22:03.000000000 -0400
> @@ -1 +1 @@
> -#define PYLIBMC_VERSION "1.1.1"
> +#define PYLIBMC_VERSION "1.1.1-agendaless1"
> 
> -- 
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1352745
> 
> Title:
>  Change buildout to not re-build libmemcached
> 
> Status in OSF KARL4:
>  Confirmed
> 
> Bug description:
>  We're not going to do all the work originally described below.
>  Instead, for now, we're only going to take libmemached out of the
>  buildout and rely on it being in the system. This might mean an update
>  to pylibmc.
> 
>  #####
> 
>  Our production (and staging) updates now take too long. It's long
>  enough to warrant some initial investigation. For this task:
> 
>  - Watch the next karlstaging build/run
>  - Identify some low-hanging fruit on what is taking a long time
>  - Give some recommendations on speeding up
> 
>  As an example, I believe we recompile memcache (or redis?) on each of
>  the four VMs, each time we update.  Is there a lib that is missing
>  from the gocept host environment? Or perhaps we're pointing to a
>  private copy?
> 
>  Other ideas:
> 
>  - Are we going to our private package repo on github for everything?
>  Can we reduce network latency by using pypi.gocept.net?
> 
>  Don't spend more than an hour on this.
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1352745/+subscriptions