From brong at fastmailteam.com Mon Mar 4 16:28:31 2019 From: brong at fastmailteam.com (Bron Gondwana) Date: Mon, 04 Mar 2019 16:28:31 -0500 Subject: Notes 5 March Message-ID: Present: Ken, Bron, ellie Ken: * going to work on drafts pre-IETF-deadline * shareWith should be done in next week or two * going to get back to following up on copyright and license discussion ellie: * it's been a while since a stable release, going to do a 3.0.9 later this week Bron: * would be good to do a 3.2 series release soon - once we're at a good stable point * planning for IETF. Next week the meeting is moving back to Monday 11am UTC (7am US East, midday Europe, 10pm Melbourne) -- Bron Gondwana, CEO, FastMail Pty Ltd brong at fastmailteam.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brong at fastmailteam.com Mon Mar 11 07:41:12 2019 From: brong at fastmailteam.com (Bron Gondwana) Date: Mon, 11 Mar 2019 07:41:12 -0400 Subject: Notes 11 March Message-ID: <89b5b94f-756d-4440-b6a6-5e1702b722ab@www.fastmail.com> Present: Ken, Robert, Bron Ken: * wrote a CGI module for HTTP in Cyrus * got all the drafts updated for IETF * facility with eventsource to give a state token at the end of streaming events. Do we want similar mechanism for push over websockets? - might have to be optional, some servers might not have a way to do a token for the user. - open issue to discuss at Prague * did some http refactoring in the code to make it easier to maintain. * found at least one thing in JMAP spec we haven't done - making settings response non-cacheable. * shareWith will be this week Robert: * partially on sick leave last week. * worked on JSContact and JSCalendar drafts for IETF. - haven't received substantial feedback yet, but may get more at IETF. * landed multi-language support on fastmailtest.com last week. * next step - maybe use additional timing information to collect data for current setup, then start collecting performance data for new setup. * implemented Blob/get * now focusing on attachment search indexing code - planning to support http based backend for text extraction with blocking requests. * could imaging defining a configurable parallel implementation - ship multiple to backend at the same time. - not sure if it's worth it, but might be! * sidetracked by issue from github - QP encoding -> we are splitting illegally within UTF-8 words. Can't reproduce that, but we do overrun the hard limit of 76 characters! Making that more RFC compliant. Current code never breaks within UTF8, but keeps going on that line rather than wrapping early. * Next: annotations topics -> will look through existing github issues. Bron: * Email from Michael Menge - making conversations DB easier for people to use / understand / manage. - should document how the tools work better - and document when it's needed! - split into two bits: conversations part and "reverse lookup" part. - make the core part non-optional. * maybe split all "per-user" databases into two files: one being master data and one being cache. * issue with sqlite and modseqs seen in the wild - still not yet debugged. - debugged LIVE on the call! We need to use sqlite3_column_int64 for the modseq fields! Next week, same time. Week after will clash with IETF. -- Bron Gondwana, CEO, FastMail Pty Ltd brong at fastmailteam.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpielorz_lst at tdx.co.uk Wed Mar 13 09:35:16 2019 From: kpielorz_lst at tdx.co.uk (Karl Pielorz) Date: Wed, 13 Mar 2019 13:35:16 +0000 Subject: Cyrus 2.5.12 - 'reconstruct' - doesn't? Message-ID: <5AC2C75F332D66F7D06BEC11@[10.12.30.106]> Hi, I have a Cyrus 2.5.12 server running under FreeBSD. The other day I found thousands of files in an old mailbox. The client can't see any of them - so I thought "Ok, I'll reconstruct the mailbox" Reconstruct runs, and returns instantly - but the client still can't see the files. As a last ditch "fix it or kill it" - I removed the cyrus.header and cyrus.index files from that folder. I expected reconstruct to rebuild them - based on the thousands of "xxxx." files in that folder - but it didn't. It just returns instantly, and no cyrus. files are created. The mailbox does exist (i.e. if I dump the mailbox database it is listed) - and clients can see the folder, just no messages in it. Any suggestion? - Is there any way to get reconstruct to be more chatty about what it's doing / not doing? Thanks, -Karl From Hagedorn at uni-koeln.de Wed Mar 13 09:55:28 2019 From: Hagedorn at uni-koeln.de (Sebastian Hagedorn) Date: Wed, 13 Mar 2019 14:55:28 +0100 Subject: Cyrus 2.5.12 - 'reconstruct' - doesn't? In-Reply-To: <5AC2C75F332D66F7D06BEC11@[10.12.30.106]> References: <5AC2C75F332D66F7D06BEC11@[10.12.30.106]> Message-ID: Hi, > I have a Cyrus 2.5.12 server running under FreeBSD. The other day I found > thousands of files in an old mailbox. > > The client can't see any of them - so I thought "Ok, I'll reconstruct the > mailbox" > > Reconstruct runs, and returns instantly - but the client still can't see > the files. > > As a last ditch "fix it or kill it" - I removed the cyrus.header and > cyrus.index files from that folder. > > I expected reconstruct to rebuild them - based on the thousands of > "xxxx." files in that folder - but it didn't. It just returns instantly, > and no cyrus. files are created. > > The mailbox does exist (i.e. if I dump the mailbox database it is listed) > - and clients can see the folder, just no messages in it. > > Any suggestion? - Is there any way to get reconstruct to be more chatty > about what it's doing / not doing? we're still on 2.4, but in my experience reconstruct doesn't recognize folders when there aren't any cyrus. files. Try to create empty cyrus.index and cyrus.header files (e.g. with touch), and run reconstruct afterwards. That should work. -- Sebastian Hagedorn - Weyertal 121, Zimmer 2.02 Regionales Rechenzentrum (RRZK) Universit?t zu K?ln / Cologne University - Tel. +49-221-470-89578 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 262 bytes Desc: not available URL: From nic at onlight.com Wed Mar 13 10:01:36 2019 From: nic at onlight.com (Nic Bernstein) Date: Wed, 13 Mar 2019 09:01:36 -0500 Subject: Cyrus 2.5.12 - 'reconstruct' - doesn't? In-Reply-To: <5AC2C75F332D66F7D06BEC11@[10.12.30.106]> References: <5AC2C75F332D66F7D06BEC11@[10.12.30.106]> Message-ID: <6dff10cf-5f25-e331-5fab-827142c1a189@onlight.com> On 3/13/19 8:35 AM, Karl Pielorz wrote: > > Hi, > > I have a Cyrus 2.5.12 server running under FreeBSD. The other day I > found thousands of files in an old mailbox. > > The client can't see any of them - so I thought "Ok, I'll reconstruct > the mailbox" > > Reconstruct runs, and returns instantly - but the client still can't > see the files. > > As a last ditch "fix it or kill it" - I removed the cyrus.header and > cyrus.index files from that folder. > > I expected reconstruct to rebuild them - based on the thousands of > "xxxx." files in that folder - but it didn't. It just returns > instantly, and no cyrus. files are created. > > The mailbox does exist (i.e. if I dump the mailbox database it is > listed) - and clients can see the folder, just no messages in it. > > Any suggestion? - Is there any way to get reconstruct to be more > chatty about what it's doing / not doing? > > Thanks, > > -Karl Karl, It would help if you told us which flags/arguments you're running reconstruct with.? Also, deleting cyrus.header was probably not a good idea.? If you want to recreate cyrus.index, remove that and run reconstruct with the '-f' or '-x' flags, depending on the state of the mailbox.? The cyrus.header file doesn't hold state, it's used to distinguish Cyrus mailboxes from other directories. However, what's probably going on here is that you have "|expunge_mode:| delayed" set, and these hidden files are actually deleted/expunged, but 'expire' hasn't been run on the mailbox. Cheers, ??? -nic -- Nic Bernstein nic at onlight.com Onlight Inc. www.onlight.com 6525 W Bluemound Rd., Ste 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 f. 414.290.0335 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpielorz_lst at tdx.co.uk Wed Mar 13 11:53:50 2019 From: kpielorz_lst at tdx.co.uk (Karl Pielorz) Date: Wed, 13 Mar 2019 15:53:50 +0000 Subject: Cyrus 2.5.12 - 'reconstruct' - doesn't? In-Reply-To: <6dff10cf-5f25-e331-5fab-827142c1a189@onlight.com> References: <5AC2C75F332D66F7D06BEC11@[10.12.30.106]> <6dff10cf-5f25-e331-5fab-827142c1a189@onlight.com> Message-ID: --On 13 March 2019 at 09:01:36 -0500 Nic Bernstein wrote: > Karl, > It would help if you told us which flags/arguments you're running > reconstruct with. Fair point - at this stage, I think I've tried everything - certainly "-G", "-R" - and just on it's own with no arguments, but the full 'path' to the specific mailbox. Sebastian has suggested a complete lack of "cyrus.*" files may result in reconstruct ignoring the mailbox - which I'll test. > Also, deleting cyrus.header was probably not a good > idea.? If you want to recreate cyrus.index, remove that and run > reconstruct with the '-f' or '-x' flags, depending on the state of the > mailbox.? The cyrus.header file doesn't hold state, it's used to > distinguish Cyrus mailboxes from other directories. Well, I was kind of clutching at straws at that point - and I did have a backup of the whole mailstore :) > However, what's probably going on here is that you have "|expunge_mode:| > delayed" set, and these hidden files are actually deleted/expunged, but > 'expire' hasn't been run on the mailbox. Yes - that could well be the case, but another reason for trying to get "reconstruct" to work is that expire thinks there's nothing to do in that mailbox either (and some of the files are years old). A big part of the struggle is stuff line: reconstruct [blah]; echo $? 0 And nothing logged anywhere (screen, or syslog)... I'll try just touching the cyrus.* files and running it - I'm also going to shut the server down out of hours (I'm pretty sure that mailbox is not open - but with the server shutdown I'm sure it will be). As I said, some of the files date back years - so just trying to get to a point where either expire will sweep them away, or reconstruct will put them back 'in the mailbox' so at least clients can see them... I'll try the above suggestions and get back with any updates. Thanks, -Karl From dave64 at andrew.cmu.edu Wed Mar 13 13:03:03 2019 From: dave64 at andrew.cmu.edu (Dave McMurtrie) Date: Wed, 13 Mar 2019 13:03:03 -0400 (EDT) Subject: Cyrus 2.5.12 - 'reconstruct' - doesn't? In-Reply-To: <5AC2C75F332D66F7D06BEC11@[10.12.30.106]> References: <5AC2C75F332D66F7D06BEC11@[10.12.30.106]> Message-ID: On Wed, 13 Mar 2019, Karl Pielorz wrote: > I have a Cyrus 2.5.12 server running under FreeBSD. The other day I found > thousands of files in an old mailbox. > > The client can't see any of them - so I thought "Ok, I'll reconstruct the > mailbox" > > Reconstruct runs, and returns instantly - but the client still can't see the > files. Are the files on disk owned by user 'cyrus' or are they owned by root? > As a last ditch "fix it or kill it" - I removed the cyrus.header and > cyrus.index files from that folder. reconstruct will create them if they don't exist. > I expected reconstruct to rebuild them - based on the thousands of "xxxx." > files in that folder - but it didn't. It just returns instantly, and no > cyrus. files are created. That is what you should expect. reconstruct will tell you about each file it finds. hth, Dave From gdmalet at uwaterloo.ca Wed Mar 13 13:34:58 2019 From: gdmalet at uwaterloo.ca (Giles Malet) Date: Wed, 13 Mar 2019 13:34:58 -0400 Subject: Cyrus 2.5.12 - 'reconstruct' - doesn't? In-Reply-To: References: <5AC2C75F332D66F7D06BEC11@[10.12.30.106]> <6dff10cf-5f25-e331-5fab-827142c1a189@onlight.com> Message-ID: <04931fa3-2021-6180-caa8-395de9de6c40@uwaterloo.ca> > but the full 'path' to the specific mailbox. Hopefully you're not giving a filesystem path. Reconstruct takes the mailbox "name", not a path on disk. So something like "user.fred" or whatever. Maybe that's why it's not finding anything. I often use the -rfGR flags, with maybe O. Someone already mentioned deleted but not expunged messages, so perhaps give the unexpunge command a try. And maybe mbexamine to see what the system thinks is going on. g From kpielorz_lst at tdx.co.uk Wed Mar 13 13:47:28 2019 From: kpielorz_lst at tdx.co.uk (Karl Pielorz) Date: Wed, 13 Mar 2019 17:47:28 +0000 Subject: Cyrus 2.5.12 - 'reconstruct' - doesn't? In-Reply-To: References: <5AC2C75F332D66F7D06BEC11@[10.12.30.106]> Message-ID: <6AE6992D044CA769E084940B@Mac-mini.local> --On 13 March 2019 at 13:03:03 -0400 Dave McMurtrie wrote: > Are the files on disk owned by user 'cyrus' or are they owned by root? All owned by cyrus:cyrus - if I pick "any other mailbox" (which looks identical disk wise) - reconstruct runs, and outputs the name of the mailbox it just reconstructed, e.g. % reconstruct user.test.somemailbox; echo $? user.test.somemailbox 0 % (this one has no issues hence no list of discovered files etc.) But for the problematic one, it just does: % reconstruct user.test.othermailbox; echo $? 0 % >> I expected reconstruct to rebuild them - based on the thousands of >> "xxxx." files in that folder - but it didn't. It just returns >> instantly, and no cyrus. files are created. > > That is what you should expect. reconstruct will tell you about each > file it finds. Ok, no error - no logs so I ktrace'd it. I can see it looks like it's looking at the mailboxes.db file (this folder *is* in mailboxes.db) - it then kind of gives up. I think I'll put this to one side until the server is shutdown - i.e. to 100% rule out anything that might be related to the mailbox possibly being locked / open. If that still fails guess I'm back to the drawing board / gdb to find out what's going on. Thanks for the replies... -Kp From kpielorz_lst at tdx.co.uk Wed Mar 13 14:18:57 2019 From: kpielorz_lst at tdx.co.uk (Karl Pielorz) Date: Wed, 13 Mar 2019 18:18:57 +0000 Subject: Cyrus 2.5.12 - 'reconstruct' - doesn't? - resolved. In-Reply-To: <6AE6992D044CA769E084940B@Mac-mini.local> References: <5AC2C75F332D66F7D06BEC11@[10.12.30.106]> <6AE6992D044CA769E084940B@Mac-mini.local> Message-ID: <1A8E1B6BC8AF92AE43D67305@Mac-mini.local> Ok, I've finally twigged / resolved this... It looks like the actual directory in question was indeed orphaned from mailboxes.db - due to an issue with names and spaces. If you miss-spell the name of the mailbox - 'reconstruct' / 'mbexamine' et'al just return without doing anything. This may be by design - but it'd be nice if they come back with "Cannot file specified mailbox in mailboxes.db" or something - anything logged or displayed, that at least hints at this going on :) As it is: reconstruct user.nonexistant Just returns immediately, setting return code zero - which was obviously confusing enough for me to post here. So, sorry for the other wise noise - and thanks again, to all who replied. -Kp From kpielorz_lst at tdx.co.uk Mon Mar 18 07:21:12 2019 From: kpielorz_lst at tdx.co.uk (Karl Pielorz) Date: Mon, 18 Mar 2019 11:21:12 +0000 Subject: Fixing stale entries in 'mailboxes.db'... Message-ID: Hi, We're running Cyrus IMAP 2.5.12 under FreeBSD. While 'spring cleaning' one of our IMAP servers - aside from having to reconstruct a mailbox, I also found in 'mailboxes.db' (seen via 'ctl_mboxlist -d') we have some entries that have no corresponding directories on the disk, e.g. user.kpielorz.Archive.1-OldLogs 16 (null) This doesn't appear to be causing an issue - but I can't see a way to remove them. e.g. If I use 'cyradm' to "cm" that mailbox, and then log in with an IMAP client - and delete it, the client correctly deletes it - and it goes from the shown hierarchy. If I then expire the deleted folder with 'cyr_expire -D0 -p DELETED.user.kpielorz' - I can see it's "really been" deleted in syslog [and from the 'DELETED' IMAP folder] - but the entry in mailboxes.db persists. Is there any way of removing these? - Are they OK to leave behind? I don't really want to have to dump / re-load mailboxes.db - there's entries in that "16 (null)" state from a long time ago - they seem to be getting 'left behind' when folders are deleted / expired? Some seem to be very, very old (so it doesn't appear they'll timeout and disappear or anything). Anyone seem similar, or know what can be done with them? Thanks, -Karl From rsto at fastmailteam.com Mon Mar 18 07:22:39 2019 From: rsto at fastmailteam.com (Robert Stepanek) Date: Mon, 18 Mar 2019 07:22:39 -0400 Subject: Cyrus Meeting - March 18, 2019 Message-ID: <42ad0ddc-85a6-4d98-9499-71fabcdff755@www.fastmail.com> Participants: Bron, Ellie, Ken, RobS Due to IETF 104 next week the call is cancelled for March 25th. We'll resume in two weeks. Bron: - spent last week on support and bug fixes around back refs Ellie: - Cyrus IMAP 3.0.9 released! - Some build problems with bleeding edge clamav despite a PR that's supposed to fix it Ken: - mostly busy with JMAP calendar shareWith last week - will add shareWith also to JMAP mailboxes - checking into Cyrus mailing list thread on partition renames RobS: - Fixed smallish JMAP bugs last weeks - Most work around Xapian search: attachment indexing, index by MIME part - Will continue Xapian work this week Cheers, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hagedorn at uni-koeln.de Mon Mar 18 07:34:12 2019 From: Hagedorn at uni-koeln.de (Sebastian Hagedorn) Date: Mon, 18 Mar 2019 12:34:12 +0100 Subject: Fixing stale entries in 'mailboxes.db'... In-Reply-To: References: Message-ID: <31B73DEA35C3341BAB470B14@tyrion.rrz.uni-koeln.de> --On 18. M?rz 2019 um 11:21:12 +0000 Karl Pielorz wrote: > We're running Cyrus IMAP 2.5.12 under FreeBSD. > > While 'spring cleaning' one of our IMAP servers - aside from having to > reconstruct a mailbox, I also found in 'mailboxes.db' (seen via > 'ctl_mboxlist -d') we have some entries that have no corresponding > directories on the disk, e.g. > > user.kpielorz.Archive.1-OldLogs 16 (null) > > This doesn't appear to be causing an issue - but I can't see a way to > remove them. > > e.g. If I use 'cyradm' to "cm" that mailbox, and then log in with an IMAP > client - and delete it, the client correctly deletes it - and it goes > from the shown hierarchy. > > If I then expire the deleted folder with 'cyr_expire -D0 -p > DELETED.user.kpielorz' - I can see it's "really been" deleted in syslog > [and from the 'DELETED' IMAP folder] - but the entry in mailboxes.db > persists. > > Is there any way of removing these? - Are they OK to leave behind? > > I don't really want to have to dump / re-load mailboxes.db - there's > entries in that "16 (null)" state from a long time ago - they seem to > be getting 'left behind' when folders are deleted / expired? Some seem to > be very, very old (so it doesn't appear they'll timeout and disappear or > anything). > > Anyone seem similar, or know what can be done with them? I believe those are "tombstone entries" to mark folders that previously existed and are are safe to keep around. -- .:.Sebastian Hagedorn - Weyertal 121 (Geb?ude 133), Zimmer 2.02.:. .:.Regionales Rechenzentrum (RRZK).:. .:.Universit?t zu K?ln / Cologne University - ? +49-221-470-89578.:. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From pgoetz at mail.utexas.edu Mon Mar 18 08:29:05 2019 From: pgoetz at mail.utexas.edu (Patrick Goetz) Date: Mon, 18 Mar 2019 07:29:05 -0500 Subject: cyrus-imapd build dependencies Message-ID: <0841d9a2-37f9-10f6-b7ce-9457f7d39fc6@mail.utexas.edu> This page on compiling cyrus-imapd: https://www.cyrusimap.org/imap/developer/compiling.html shows a number of build dependencies; however I was just able to compile cyrus-imapd without these installed: gperf libbsd Are these actually necessary? Later in the page, under "Alternate database formats" it shows the configure flags to use in order to use mysql/mariadb as a backend for cyrus databases. I think this is needed if one plans to use virtual domains, but I couldn't get a confirmation on this. In any case, the configure options are given as --with-mysql, --with-mysql-incdir, --with-mysql-libdir with no clear indication of what each of these does. For example, is the --with-mysql all inclusive, or does one need to set all 3? Finally a couple of items in the "Other" category are a real head scratcher. For example, what is the purpose of net-snmp? libnghttp2 is listed as needed for "HTTP/2 support for httpd" -- what's using httpd? Is this to faciliate CalDAV/CardDAV? From kpielorz_lst at tdx.co.uk Mon Mar 18 17:39:21 2019 From: kpielorz_lst at tdx.co.uk (Karl Pielorz) Date: Mon, 18 Mar 2019 21:39:21 +0000 Subject: Fixing stale entries in 'mailboxes.db'... In-Reply-To: <31B73DEA35C3341BAB470B14@tyrion.rrz.uni-koeln.de> References: <31B73DEA35C3341BAB470B14@tyrion.rrz.uni-koeln.de> Message-ID: --On 18 March 2019 at 12:34:12 +0100 Sebastian Hagedorn wrote: >> user.kpielorz.Archive.1-OldLogs 16 (null) >> >> [snip] >> >> Anyone seem similar, or know what can be done with them? > > I believe those are "tombstone entries" to mark folders that previously > existed and are are safe to keep around. Ok, I'll leave them alone on that basis. Sadly we have far more of them than active folders on the system, they must have built up over time (but it's not like they're taking a lot of space / resources though). I guess dumping mailboxes.db through grep -v etc. and re-importing would remove them, but as I originally said I don't really want to do that on the system. Thanks for the reply, -Karl From ellie at fastmail.com Mon Mar 18 21:19:19 2019 From: ellie at fastmail.com (ellie timoney) Date: Mon, 18 Mar 2019 21:19:19 -0400 Subject: Fixing stale entries in 'mailboxes.db'... In-Reply-To: References: <31B73DEA35C3341BAB470B14@tyrion.rrz.uni-koeln.de> Message-ID: On Tue, Mar 19, 2019, at 8:42 AM, Karl Pielorz wrote: > > > --On 18 March 2019 at 12:34:12 +0100 Sebastian Hagedorn > wrote: > > >> user.kpielorz.Archive.1-OldLogs 16 (null) > >> > >> [snip] > >> > >> Anyone seem similar, or know what can be done with them? > > > > I believe those are "tombstone entries" to mark folders that previously > > existed and are are safe to keep around. > > Ok, I'll leave them alone on that basis. Sadly we have far more of them > than active folders on the system, they must have built up over time (but > it's not like they're taking a lot of space / resources though). > > I guess dumping mailboxes.db through grep -v etc. and re-importing would > remove them, but as I originally said I don't really want to do that on the > system. > > Thanks for the reply, > > -Karl > They're (briefly) important for recovering from split brain replication situations -- if one server has the mailbox and the other server doesn't, is it a new mailbox that needs to be created, or a deleted mailbox that needs to be deleted? The tombstone records provide the answer. If one server has the mailbox and the other has a tombstone for it, then it knows to delete the mailbox. If one server has the mailbox and the other has nothing, then it knows to create the mailbox. I'm not sure if they're also used for anything else -- possibly not in 2.5, but maybe in later versions. They should be cleaned up by cyr_expire after they're 7 days old (this will eventually be configurable, but in 2.5 it is what it is). This behaviour is turned _off_ by the '-x' argument, so if all your scheduled cyr_expire runs include the '-x' argument, nothing will clean them up... Cheers, ellie From pgoetz at mail.utexas.edu Wed Mar 20 08:39:44 2019 From: pgoetz at mail.utexas.edu (Patrick Goetz) Date: Wed, 20 Mar 2019 07:39:44 -0500 Subject: segfaults with cyrus-imapd 3.0.9 on latest arch linux In-Reply-To: <57f4ab86-ece1-b6ba-0120-80e175a2999c@mailbox.org> References: <9cee911b-baf4-6faa-4dac-dd97e0eaa550@mailbox.org> <16f63075-b579-f910-4d11-b08644793fea@mail.utexas.edu> <57f4ab86-ece1-b6ba-0120-80e175a2999c@mailbox.org> Message-ID: Hi - I can confirm this segmentation fault on my own Arch VM with cyrus installed from the AUR package. As an experiment, I tried building the package with --disable-pcre but then I can't even get the program to compile: ---------------------------- In file included from lib/glob.c:50: lib/glob.h:57:5: error: unknown type name ?regex_t? regex_t regex; ^~~~~~~ lib/glob.c: In function ?glob_init?: lib/glob.c:112:5: warning: implicit declaration of function ?regcomp?; did you mean ?memcmp?? [-Wimplicit-function-declaration] regcomp(&g->regex, buf_cstring(&buf), REG_EXTENDED); ^~~~~~~ memcmp lib/glob.c:112:43: error: ?REG_EXTENDED? undeclared (first use in this function) regcomp(&g->regex, buf_cstring(&buf), REG_EXTENDED); ^~~~~~~~~~~~ ---------------------------- It would appear that --disable-pcre is a configuration option you can't actually use. On 3/19/19 5:37 PM, Andreas Piesk wrote: > Am 19.03.19 um 22:00 schrieb Patrick Goetz: >> >> Have you tried the 3.0.9 AUR package? >> >> ?? https://aur.archlinux.org/packages/cyrus-imapd >> >> Once you get the dependencies down, this one compiles and runs. >> > > I noticed the package, it's good to see a recent version in AUR but it > has too many dependecies for my taste, I need a stripped down version. > > Unfortunately the AUR package doesn't work for me either, i build it in > a VM with a fresh installed arch and it has the same problem: > > Starting program: /usr/bin/cyrdump user/test > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/usr/lib/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff7c76205 in re_compile_internal () from /usr/lib/libc.so.6 > (gdb) bt > #0? 0x00007ffff7c76205 in re_compile_internal () from /usr/lib/libc.so.6 > #1? 0x00007ffff7c77511 in regcomp () from /usr/lib/libc.so.6 > #2? 0x00007ffff7e3d980 in glob_init () from /usr/lib/libcyrus.so.0 > #3? 0x00007ffff7f38276 in ?? () from /usr/lib/libcyrus_imap.so.0 > #4? 0x00007ffff7f3e5b7 in mboxlist_findallmulti () from > /usr/lib/libcyrus_imap.so.0 > #5? 0x00005555555561aa in ?? () > #6? 0x00007ffff7bbb223 in __libc_start_main () from /usr/lib/libc.so.6 > #7? 0x00005555555561ee in ?? () > > > Best Regards, > -ap > > > ---- > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus > From pgoetz at mail.utexas.edu Wed Mar 20 12:11:01 2019 From: pgoetz at mail.utexas.edu (Patrick Goetz) Date: Wed, 20 Mar 2019 11:11:01 -0500 Subject: segfaults with cyrus-imapd 3.0.9 on latest arch linux In-Reply-To: <57f4ab86-ece1-b6ba-0120-80e175a2999c@mailbox.org> References: <9cee911b-baf4-6faa-4dac-dd97e0eaa550@mailbox.org> <16f63075-b579-f910-4d11-b08644793fea@mail.utexas.edu> <57f4ab86-ece1-b6ba-0120-80e175a2999c@mailbox.org> Message-ID: <7268abd5-40cf-654e-fd79-cb15e74948c1@mail.utexas.edu> Hi Andreas - Jakob has already updated the AUR package, which appears to have resolved this issue. The related upstream bug is #2629. Regarding the dependencies in the cyrus-imapd PKGBUILD. I recommend starting with Jakob's PKGBUILD and just stripping out the stuff you don't need. I've spent so much time looking at it at this point, if you tell me what you don't want, I can probably post a PKGBUILD that works for your requirements. In any case, please try cyrus-imapd 3.0.9-2 and let me know if this resolves the issue for you, too. Here is an explanation (provided by the AUR package maintainer) of the purpose of the various dependencies he's included (also the ones listed as requirements which he did not include). We had pre-agreed that there is no harm in compiling in all the authentication hooks and CalDAV/CalCard dependencies. Without the authentication hooks, the package isn't really general purpose. - gperf seems to be useful for development only (maintainer mode) - libbsd is only required for krb5afspts which is disabled (because IIRC it looks for static libraries which Arch doesn?t package) - ICU: This seems to be genuinely missing, though as you noticed it is already required indirectly. It is probably still a good idea to make that dependency explicit. But since it?s a relatively minor problem I?ll wait to see if anything else comes up in our conversation so I can ?bundle? the changes. - clamav is in fact already in optdepends, however in order to build against it it needs to be in makedepends as well - xapian-core provides efficient indexed search, which I?d argue is quite a useful feature to have in a mail server. It is linked into libcyrus_imap.so though, which is in turn linked into imapd (unlike clamav), therefore it is a hard dependency. - libcap allows Cyrus?s services to restrict their own capabilities(7) for enhanced security - libnghttp2 and brotli add support for HTTP/2 and Brotli compression of HTTP responses, respectively; which is relevant to CalDAV, CardDAV and other HTTP services (including JMAP in future versions) - shapelib allows Cyrus?s Time Zone Distribution Service[2] to associate time zones with geographical locations - python-sphinx, perl-pod-pom-view-restructured: required for generation of some manpages (which are included in the regular package, not the -docs one. I?d argue that manpages are actually useful to have around). These are only needed at buildtime and need not be present on the actual server system. On 3/19/19 5:37 PM, Andreas Piesk wrote: > Am 19.03.19 um 22:00 schrieb Patrick Goetz: >> >> Have you tried the 3.0.9 AUR package? >> >> ?? https://aur.archlinux.org/packages/cyrus-imapd >> >> Once you get the dependencies down, this one compiles and runs. >> > > I noticed the package, it's good to see a recent version in AUR but it > has too many dependecies for my taste, I need a stripped down version. > > Unfortunately the AUR package doesn't work for me either, i build it in > a VM with a fresh installed arch and it has the same problem: > > Starting program: /usr/bin/cyrdump user/test > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/usr/lib/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff7c76205 in re_compile_internal () from /usr/lib/libc.so.6 > (gdb) bt > #0? 0x00007ffff7c76205 in re_compile_internal () from /usr/lib/libc.so.6 > #1? 0x00007ffff7c77511 in regcomp () from /usr/lib/libc.so.6 > #2? 0x00007ffff7e3d980 in glob_init () from /usr/lib/libcyrus.so.0 > #3? 0x00007ffff7f38276 in ?? () from /usr/lib/libcyrus_imap.so.0 > #4? 0x00007ffff7f3e5b7 in mboxlist_findallmulti () from > /usr/lib/libcyrus_imap.so.0 > #5? 0x00005555555561aa in ?? () > #6? 0x00007ffff7bbb223 in __libc_start_main () from /usr/lib/libc.so.6 > #7? 0x00005555555561ee in ?? () > > > Best Regards, > -ap > > > ---- > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus > From dilyan.palauzov at aegee.org Sun Mar 24 12:25:32 2019 From: dilyan.palauzov at aegee.org (=?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?=) Date: Sun, 24 Mar 2019 16:25:32 +0000 Subject: To: and qouted strings Message-ID: <9cf68d36c74b082ab0b5b3fdf58c1269cb006bc6.camel@aegee.org> Hello, PUTting a new meeting with ATTENDEE;CN="X, Y":MAILTO:a at b sends over 3.0/imap/imip_send_sendmail() to sendmail: To: X, Y which sendmail normalizes to To: X at fqdm, Y The string X, Y must be quoted, as described in RFC5322 Section 3.2.4 ?Quoted Strings?. Is there code in cyrus, that does such quoting, when necessary? I found prot_printstring() which works on struct protstream, but the need is for operating on char* or struct buf. The codebase will benefit, if somebody does deduplication. There is code on several places generating message boundaries, or calculating the sieve paths for a user. There is lib/prot.c:isQCHAR which seems and sounds very similar to lib/rfc822tok.c:is_special. A const array with the value ?{ "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" }? is defined in imap/http_tzdist.c, imap/httpd.c, and lib/times.c, but a single cyrus-wide definition will be sufficient. Likewise, a there are several definitions of the weekdays. Regards ????? From dilyan.palauzov at aegee.org Sat Mar 30 10:57:30 2019 From: dilyan.palauzov at aegee.org (=?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?=) Date: Sat, 30 Mar 2019 14:57:30 +0000 Subject: Scheduling VJOURNAL Message-ID: Hello, iCalendar forsees for VJOURNAL, VEVENT and VTODO attendees and organizer. Scheduling Extensions to CalDAV says nothing about VJOURNAL. iTIP foresees VJOURNAL. In imap/http_caldav.c:caldav_put() has switch (kind) { case ICAL_VEVENT_COMPONENT: case ICAL_VTODO_COMPONENT: case ICAL_VPOLL_COMPONENT: if (organizer) DO SOMETHING, possibly sending an email case ICAL_VJOURNAL_COMPONENT: DO NOTHING I do expect, when I upload a VJOURNAL with attendees on different hosts, that the participants receive a mail (on each change). Do you think it is reasonable to move ?case ICAL_VJOURNAL_COMPONENT? before ?if (organizer)?, so that for local users HTTP scheduling happens, or shall uploading VJOURNAL with ATTENDEEs always trigger emails? Regards ????? From murch at fastmail.com Sat Mar 30 15:51:39 2019 From: murch at fastmail.com (Ken Murchison) Date: Sat, 30 Mar 2019 15:51:39 -0400 Subject: Scheduling VJOURNAL In-Reply-To: References: Message-ID: Yes, if VJOURNAL can be scheduled then we should support it. On 3/30/19 10:57 AM, ????? ???????? wrote: > Hello, > > iCalendar forsees for VJOURNAL, VEVENT and VTODO attendees and organizer. > > Scheduling Extensions to CalDAV says nothing about VJOURNAL. iTIP foresees VJOURNAL. > > In imap/http_caldav.c:caldav_put() has > > switch (kind) { > case ICAL_VEVENT_COMPONENT: > case ICAL_VTODO_COMPONENT: > case ICAL_VPOLL_COMPONENT: > if (organizer) > DO SOMETHING, possibly sending an email > case ICAL_VJOURNAL_COMPONENT: > DO NOTHING > > I do expect, when I upload a VJOURNAL with attendees on different hosts, that the participants receive a mail (on each > change). > > Do you think it is reasonable to move ?case ICAL_VJOURNAL_COMPONENT? before ?if (organizer)?, so that for local users > HTTP scheduling happens, or shall uploading VJOURNAL with ATTENDEEs always trigger emails? > > Regards > ????? > -- Ken Murchison Cyrus Development Team FastMail US LLC -------------- next part -------------- A non-text attachment was scrubbed... Name: murch.vcf Type: text/x-vcard Size: 4 bytes Desc: not available URL: