similar to: Cooperating with dovecot in its Maildir

I was hoping someone might be able to tell me the current status of direct rendering support? Is it possible to run Xen on a machine and have X DRI (Direct Rendering) work in at least one of the domains? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

I was wondering if it's possible to restrict rsync in various ways on the server side when it is invoked via ssh. Two restrictions I had in mind are disallowing deletes and/or restricting all actions to a particular subdirectory. I was hoping to be able to do this without having to be root (for a chroot) or having to set up special sshd server instances/chroots. If there's not already a

Hello, i need for an old bios-update the programm "lockfile". The update-bin make a check via "which lockfile". I have installed "lockfile-progs.x86_64" on a CentOS 5.8 and i have the programm "lockfile" and "lockfile-check, lockfile-create, lockfile-remove, lockfile-touch" in /usr/bin/. On my CentOS 6.2 i have install the pakage

I've installed logcheck on CentOS from source, as well as liblockfile and lockfile-progs. I've created a logcheck user with /var/lib/logcheck as the home and /sbin/nologin as the shell. logcheck user is in the adm group. I also customised the list of logfiles for CentOS. When I run logcheck, I get the following errors: # sudo -u logcheck logcheck -ot basename: invalid option -- - Try

Dear all, I''m seeing this strange thing: When I run "*puppet agent -td*" on the node (Nagios, in this example case), puppet fails to install Nagios3 (on Debian) with this: Debug: Executing ''/usr/bin/dpkg-query -W --showformat ${Status} ${Package} > ${Version}\n nagios3'' > Debug: Executing ''/usr/bin/apt-get -q -y -o >

I've finally managed to run Dovecot without errors in two computers with maildir and indexes stored in NFS. I added a page to wiki about this: http://wiki.dovecot.org/NFS Suggestions how to keep attribute cache enabled but to allow Dovecot to specifically request not to use a cached value (when it's important) would be welcome. -------------- next part -------------- A non-text

Dear Experts, I'm hoping that your experience with SMB and CIFS means that you're familiar with cross-platform file locking. I need a lowest-common-denominator whole-file locking method that will work on as many combinations of client and server systems as possible; in particular it needs to run on - Linux client talking to NFS server. - Linux client talking to Samba server. - Linux

Good day folks, I'm using Samba 2.2.8a [1] on Slackware 9.1 with 2000/XP clients. I'm attempting to have a process by which a user drags a file using Windows Explorer into a share. On the server side, I have a unix process that polls the directory for new files and then reads them and deletes them. I'm having a problem where I can gain the lock but the process is still writing to

Greetings, I think I may be having a slight configuration problem with Samba and FreeBSD-5.1. I'm trying to use FreeBSD's mount_smbfs(8) to mount a remote Samba share onto my local FreeBSD filesystem. With the configuration below, I can read all (almost; explained below) files and directories just fine. All permissions are correct. But whenever I try to write to the share, the write fails

Hi, I'm having a problem getting my Windows machines to access shares in Samba. When they browse to the Samba box it sometimes gives them an error saying that they don't have permission or that the server is unavailable. However this doesn't always happen and other times it lists the shares. When I try to access the shares it just prompts for the username/password over and over.

Javier Garcia <javiertury at gmail.com> writes: > I've applied the path to notmuch 0.26.1 without success. > > $ rm -rf ~/.mail/.notmuch > $ LD_LIBRARY_PATH=/hidden-path/notmuch-0.26.1/lib/:$LD_LIBRARY_PATH > ./notmuch new >    Found 20065 total files (that's not much mail). >    Processed 20065 total files in 58s (341 files/sec.). >    Added 19605 new

Hi notmuch developers, I also had this database corruption, I waited for the fix to land in notmuch 0.26.2, build it, moved the xapian directory away, did a notmuch new and restored the tags from a dump. But the problem remains: ~$ xapian-check ~/Mail/.notmuch/xapian docdata: blocksize=8K items=10841 firstunused=75 revision=82 levels=1 root=2 B-tree checked okay docdata table structure checked

Running notmuch from git on Debian testing[1] with the mail and database sitting on a ZFS filesystem, adding mail to a new database: > agrajag-testing ~/s/notmuch % ./notmuch new > Found 605510 total files (that's not much mail). > add_file: A Xapian exception occurred36m 37s remaining). > A Xapian exception occurred adding message: Unexpected end of posting list for

Hi! Suppose you have a huge notmuch/Xapian database, built on a 32-bit system (well, actually on x86_64-pc-linux-gnu, but using a years old 32-bit notmuch binary; notmuch 0.9, Xapian 1.2.21 -- don't laugh), and suppose you're finally going to update that years old notmuch installation (release by release, forward-porting a bunch of patches). Naturally, I'd now do a native 64-bit

Mueen Nawaz <mueen at nawaz.org> writes: > After a lot of poking around, I figured out the problem, and this may be > of interest to the developers (although not sure if it is a xapian issue > or a notmuch issue). > > Here's why it would freeze: > > I have a post-new hook that runs a Python script. Depending on whether > the new email it is processing matches a

Matt <mattator at gmail.com> writes: > thanks didn't know about xapian-check ! > the output > === > docdata: > blocksize=8K items=70 firstunused=3 revision=421 levels=0 root=2 > B-tree checked okay > docdata table structure checked OK > > termlist: > blocksize=8K items=186136 firstunused=62058 revision=421 levels=2 root=12260 > B-tree checked okay >

I hadn't noticed any interactive slowdown, but when I got around to running the notmuch performance suite, there seems to be some noticable slowdown with the glass backend (default in Xapian 1.3.5) compared to chert (using xapian 1.2.22) These tests are on an older i7 with 12G of RAM and an SSD. I'm reasonable confident they are CPU bound. One curious thing is the increase in system time

On Thu Apr 23 00:21:30 2020, Olly Betts <olly at survex.com> wrote: > First question: what version of Xapian are you using? On my laptop it's 1.4.15 (arch linux) and the desktop runs 1.4.14 (Gentoo linux) > And second thing to check, are you committing each message separately? No, I sync with mbsync which dosnloads a bunch of mails, then I run notmuch new which indexes all in

Franz Fellner <alpine.art.de at gmail.com> writes: > I also suffer from bad performance of notmuch new. I used notmuch > some years ago and notmuch new always felt instantanious. Had to stop > using it because internet was too slow to sync my mails :/ Now (with > better internet and a completely new setup using mbsync) indexing one > mail takes at least 10 seconds,

David Bremner <david at tethera.net> writes: >> Here's why it would freeze: >> >> I have a post-new hook that runs a Python script. Depending on >> whether the new email it is processing matches a rule I have, >> it will fire off an email to the sender using the SMTP library >> in Python. >> >> I had recently upgraded my MTA