similar to: [PATCH] linux/inotify.h: do not include <linux/fcntl.h> in userspace

"Kirill A. Shutemov" <kirill at shutemov.name> writes: > Hello, > > I found that on particular queries notmuch return different results if run > the query few times. Re-initialing the query or db doesn't help. > > I've attached test case along with corpus of messages. > > Unpack the archive and run `make' there. It will initialize the notmuch

Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Existing Mesa drivers are still aware of only these older format modifiers which do not differentiate between different variations of the block linear layout. When the format modifier support flag was flipped in the nouveau kernel driver, the X.org modesetting driver

On Wed, 29 Jul 2020 at 12:48, Dave Airlie <airlied at gmail.com> wrote: > > On Tue, 28 Jul 2020 at 04:51, James Jones <jajones at nvidia.com> wrote: > > > > On 7/23/20 9:06 PM, Ben Skeggs wrote: > > > On Sat, 18 Jul 2020 at 13:34, James Jones <jajones at nvidia.com> wrote: > > >> > > >> Accept the

On 7/23/20 9:06 PM, Ben Skeggs wrote: > On Sat, 18 Jul 2020 at 13:34, James Jones <jajones at nvidia.com> wrote: >> >> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() >> family of modifiers to handle broken userspace >> Xorg modesetting and Mesa drivers. Existing Mesa >> drivers are still aware of only these older >> format modifiers which do not

Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Existing Mesa drivers are still aware of only these older format modifiers which do not differentiate between different variations of the block linear layout. When the format modifier support flag was flipped in the nouveau kernel driver, the X.org modesetting driver

Use klibc way to define a system dependent preprocessor definition: disabled by default and enabled for newer arm. Based on a patch by vorlon that got tested on his beagleboard, should be functional equivalent. Fixes: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/527720 Cc: Steve Langasek <steve.langasek at canonical.com> Cc: Kirill A. Shutemov <kirill at shutemov.name> Cc:

It turns out that I forgot to go through and make sure that I converted all encoder callbacks to use atomic_enable/atomic_disable(), so let's go and actually do that. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Kirill A. Shutemov <kirill at shutemov.name> Fixes: 09838c4efe9a ("drm/nouveau/kms: Search for encoders' connectors properly") ---

hi, the current code has changed include linux/inotify.h to sys/inotify.h since 2006-01-17, but that won't work with inotify*.h as documented in the wiki. One has to either revert back to linux/inotify.h, or add #include <sys/inotify-syscalls.h> to both configure.in and src/lib/ioloop-notify-inotify.c Or, just symlink sys/inotify.h -> linux/inotify.h. That's on Debian 3.1

Hi, I note that dovecot supported inotify from -test77, and now the Linux kernel supports it starting from linux-2.6.13-rc3. So in theory I should be set to go. I'm using an -mm kernel, and it was built with inotify, on FC4/devel. However when trying to build with it using --with-notify=inotify, I always seem to be getting this message: checking for poll... yes configure: error:

Hi, dovecot (1.0.alpha5) won't compile with inotify support because inotify.h can't be found. I'm running Linux 2.6.15-rc5 with headers from 2.6.12 (like most vendors). I've noticed that beagle and other inotify-enabled applications ships with an inotify.h. Could this be scheduled for alpha6? :-)

Hi, I'm trying to compile Dovecot beta2 with inotify support, but this is unsuccessfull. First, it seems that the configure script is looking for inotify.h in /usr/include/sys, whereas it is in /usr/include/linux on my Debian Sarge system. But that's a minor point, let's make a symlink. % dpkg -S /usr/include/linux/inotify.h linux-kernel-headers: /usr/include/linux/inotify.h % dpkg

Hello, I've a problem on my system with inotify. In the smbd logfile are shown a lot messages like this: [2015/06/10 11:15:21.644453, 0, pid=57030, effective(12700, 100), real(0, 0)] smbd/notify_inotify.c:297(inotify_setup) Failed to init inotify - Too many open files [2015/06/10 11:15:23.968497, 0, pid=57030, effective(12700, 100), real(0, 0)] smbd/notify_inotify.c:297(inotify_setup)

(dovecot v1.2.16) I've notice the log notices about increasing /proc/sys/fs/inotify/max_user_instances on my servers, and started wondering if inotify works for network/cluster filesystems.. I found this: http://www.ibm.com/developerworks/forums/thread.jspa?threadID=311194 which says that there's no mechanism for one node to tell another node that a directory changed for GPFS.. And I

how about gluste's own client(s)? You mount volume (locally to the server) via autofs/fstab and watch for inotify on that mountpoing(or path inside it). That is something I expected was out-of-box. On 03/05/18 17:44, Joe Julian wrote: > There is the ability to notify the client already. If you > developed against libgfapi you could do it (I think). > > On May 3, 2018 9:28:43 AM

The previous code: fcntl (fd, F_SETFL, O_NONBLOCK) was technically incorrect, because it would have reset any other flags on the file descriptor. Thanks: Eric Blake --- bootstrap | 1 + daemon/inotify.c | 6 ++++-- lib/conn-socket.c | 21 +++++++++++---------- m4/.gitignore | 9 +++++++++ 4 files changed, 25 insertions(+), 12 deletions(-) diff --git a/bootstrap b/bootstrap

hello vorlon, got notified of your patch, will apply next days upstream unless some critiques are voiced on ml. thanks. -- maks ----- Forwarded message from Steve Langasek <steve.langasek at canonical.com> ----- Date: Wed, 16 Feb 2011 22:05:42 -0000 From: Steve Langasek <steve.langasek at canonical.com> Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses

Hey, I thought about it a while back, haven't actually done it but I assume using inotify on the brick should work, at least in replica volumes (disperse probably wouldn't, you wouldn't get all events or you'd need to make sure your inotify runs on every brick). Then from there you could notify your clients, not ideal, but that should work. I agree that adding support for inotify

I'm seeing this message in my /var/log/maillog: May 26 12:35:00 agencymail dovecot: IMAP(info at example.com): Inotify instance limit for user exceeded, disabling. Increase /proc/sys/fs/inotify/max_user_instances I rummaged through google, and found : http://www.dovecot.org/list/dovecot-cvs/2008-May/011132.html which says I need to increase /proc/sys/fs/inotify/max_user_instances (no

Hi, I recently switched from courier imap to dovecot. With courier I had a working IDLE setup that informed me immediately when new mail arrived. With Dovecot it is different, sometimes i get an immediate result but most of the time it takes a rather long time for the notification to return to the client. For testing purposes I set mailbox_idle_check_interval = 1 and i now get the same

There is the ability to notify the client already. If you developed against libgfapi you could do it (I think). On May 3, 2018 9:28:43 AM PDT, lemonnierk at ulrar.net wrote: >Hey, > >I thought about it a while back, haven't actually done it but I assume >using inotify on the brick should work, at least in replica volumes >(disperse probably wouldn't, you wouldn't get