Comment 6 for bug 1352745

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