diff --git a/packages/x11/lib/libxcb/meta b/packages/x11/lib/libxcb/meta
index 386078417f..8c52e0a615 100644
--- a/packages/x11/lib/libxcb/meta
+++ b/packages/x11/lib/libxcb/meta
@@ -19,7 +19,7 @@
 ################################################################################
 
 PKG_NAME="libxcb"
-PKG_VERSION="1.7"
+PKG_VERSION="1.8"
 PKG_REV="1"
 PKG_ARCH="any"
 PKG_LICENSE="OSS"
diff --git a/packages/x11/lib/libxcb/patches/libxcb-1.7-wait_for_reply.patch b/packages/x11/lib/libxcb/patches/libxcb-1.7-wait_for_reply.patch
deleted file mode 100644
index 6f9f795d73..0000000000
--- a/packages/x11/lib/libxcb/patches/libxcb-1.7-wait_for_reply.patch
+++ /dev/null
@@ -1,53 +0,0 @@
-commit 5ceeaaa4294201b3f613c07f9ec610c0e5f673c7
-Author: Uli Schlachter <psychon@znc.in>
-Date:   Thu Aug 25 14:18:16 2011 +0200
-
-    Fix a dead-lock due to xcb_poll_for_reply
-    
-    Imagine two threads:
-    
-    Thread#1: for(;;) { xcb_get_input_focus_reply(c, xcb_get_input_focus(c), 0); }
-    
-    Thread#2: for(;;) { xcb_poll_for_event(c); }
-    
-    Since xcb_poll_for_event() calls _xcb_in_read() directly without synchronizing
-    with any other readers, this causes two threads to end up calling recv() at the
-    same time. We now have a race because any of these two threads could get read
-    the GetInputFocus reply.
-    
-    If thread#2 reads this reply, it will be put in the appropriate queue and
-    thread#1 will still be stuck in recv(), although its reply was already received.
-    If no other reply or event causes this thread to wake up, the process deadlocks.
-    
-    To fix this, we have to make sure that there is only ever one thread reading
-    from the connection. The obvious solution is to check in poll_for_next_event()
-    if another thread is already reading (in which case c->in.reading != 0) and not
-    to read from the wire in this case.
-    
-    This solution is actually correct if we assume that the other thread is blocked
-    in poll() which means there isn't any data which can be read. Since we already
-    checked that there is no event in the queue this means that
-    poll_for_next_event() didn't find any event to return.
-    
-    There might be a small race here where the other thread already determined that
-    there is data to read, but it still has to wait for c->iolock. However, this
-    means that the next poll_for_next_event() will be able to read the event, so
-    this shouldn't cause any problems.
-    
-    Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=40372
-    
-    Signed-off-by: Uli Schlachter <psychon@znc.in>
-    Signed-off-by: Peter Harris <pharris@opentext.com>
-
-diff -uNr libxcb-1.7/src/xcb_in.c libxcb-1.7-patched/src/xcb_in.c
---- libxcb-1.7/src/xcb_in.c	2010-08-13 13:43:31.000000000 +0200
-+++ libxcb-1.7-patched/src/xcb_in.c	2011-09-09 06:59:26.990634243 +0200
-@@ -548,7 +548,7 @@
-         pthread_mutex_lock(&c->iolock);
-         /* FIXME: follow X meets Z architecture changes. */
-         ret = get_event(c);
--        if(!ret && _xcb_in_read(c)) /* _xcb_in_read shuts down the connection on error */
-+        if(!ret && c->in.reading == 0 && _xcb_in_read(c)) /* _xcb_in_read shuts down the connection on error */
-             ret = get_event(c);
-         pthread_mutex_unlock(&c->iolock);
-     }