Package Details: mu 1.8.3-1

Git Clone URL: (read-only, click to copy)
Package Base: mu
Description: Maildir indexer/searcher and Emacs client (mu4e)
Upstream URL:
Licenses: GPL
Submitter: xyproto
Maintainer: mroethke
Last Packager: mroethke
Votes: 35
Popularity: 4.26
First Submitted: 2019-03-27 09:21 (UTC)
Last Updated: 2022-07-03 16:34 (UTC)

Latest Comments

ra1nb0w commented on 2022-07-03 18:07 (UTC)

@mroethke thank you very much. We will see ;-)

mroethke commented on 2022-07-03 16:34 (UTC)

@ra1nb0w I have disabled guile for now, but might reenable it if enough people complain.

ra1nb0w commented on 2022-07-01 10:26 (UTC)

From version 1.8 the current guile support has been deprecated. Therefore, I suggest to remove that cumbersome dependency or made a new mu-guile aur since from what I read in mu ml/issues it has very little usage. What do you think?


mroethke commented on 2022-06-29 20:22 (UTC)

@milouse Thanks for reminding me that arch-meson exists!

@prosoitos Unfortunately I cannot answer that question. I know next to nothing about emacs. But I do know that I do not do anything special in this package. If I had to guess I would say that meson does something different from autotools or something changed in 1.8. Since those problems seem to be new. I will do some digging tomorrow.

prosoitos commented on 2022-06-29 17:58 (UTC)


2 errors mentioned in this issue in the mu repo might stem from the packaging here maybe?

Thank you!

milouse commented on 2022-06-27 08:32 (UTC)


Is there a specific reason you don’t want to use the arch-meson wrapper in the prepare step? i.e. instead of the current prepare function, use something like:

prepare() {
    arch-meson -Dguile=enabled -Dreadline=enabled "$pkgname-$pkgver" build

mroethke commented on 2022-06-18 09:01 (UTC)

@xeruf That file is (re)generated by a pacman hook on install. So it makes sense that it does not belong to any package. However, even when not building in a clean chroot I can not reproduce your issue. And I have no idea how or why that file could end up in the package.

@xavierbaez It looks like your gcc-libs package is to old. Please do a full upgrade and try again or ideally build in a clean chroot.

xavierbaez commented on 2022-06-08 22:01 (UTC)

THe package is not building correctly: CXXLD test-threads CXXLD test-contacts CXXLD test-parser /usr/bin/ld: /usr/lib/ undefined reference to std::__throw_bad_array_new_length()@GLIBCXX_3.4.29' collect2: error: ld returned 1 exit status /usr/bin/ld: /usr/lib/ undefined reference tostd::__throw_bad_array_new_length()@GLIBCXX_3.4.29' collect2: error: ld returned 1 exit status make[3]: [Makefile:1015: test-msg] Error 1 make[3]: Waiting for unfinished jobs.... make[3]: [Makefile:1031: test-store] Error 1 /usr/bin/ld: /usr/lib/ undefined reference to std::__throw_bad_array_new_length()@GLIBCXX_3.4.29' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:1023: test-parser] Error 1 /usr/bin/ld: /usr/lib/ undefined reference tostd::__throw_bad_array_new_length()@GLIBCXX_3.4.29' collect2: error: ld returned 1 exit status make[3]: [Makefile:1027: test-query] Error 1 /usr/bin/ld: /usr/lib/ undefined reference to `std::__throw_bad_array_new_length()@GLIBCXX_3.4.29' collect2: error: ld returned 1 exit status make[3]: [Makefile:1035: test-threads] Error 1 make[3]: Leaving directory '/home/xavier/.cache/yay/mu/src/mu-1.6.11/lib' make[2]: [Makefile:1175: all-recursive] Error 1 make[2]: Leaving directory '/home/xavier/.cache/yay/mu/src/mu-1.6.11/lib' make[1]: [Makefile:583: all-recursive] Error 1 make[1]: Leaving directory '/home/xavier/.cache/yay/mu/src/mu-1.6.11' make: [Makefile:493: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

xeruf commented on 2022-06-07 17:01 (UTC)

well, obviously this is some kind of conflict that won't happen in a clean environment, but interestingly:

❯ stat /usr/share/info/dir
  File: /usr/share/info/dir
  Size: 117309      Blocks: 232        IO Block: 4096   regular file
Device: 259,3   Inode: 3299089     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-06-07 19:00:15.651702890 +0200
Modify: 2022-06-07 18:47:30.399224429 +0200
Change: 2022-06-07 18:47:30.399224429 +0200
 Birth: 2020-12-12 17:57:15.674679295 +0100
❯ sudo pacman -Qo /usr/share/info/dir
error: No package owns /usr/share/info/dir

mroethke commented on 2022-06-06 10:25 (UTC)

I cannot reproduce this, have you tried building this in a clean chroot?

xeruf commented on 2022-06-05 21:16 (UTC)

Unable to update :/

error: failed to commit transaction (conflicting files)
mu: /usr/share/info/dir exists in filesystem
Errors occurred, no packages were upgraded.

mroethke commented on 2022-02-25 12:24 (UTC)

That is probably a problem with the package you are using. It must provide, and probably conflict with, emacs, like for instance the emacs-git package is doing.

greenbeast commented on 2022-02-24 17:40 (UTC)

I have Emacs 29 installed and it seems like it doesn't recognize that because it also tried installing emacs 27.2 as well.

mroethke commented on 2021-11-15 18:33 (UTC)

Please try to build in a clean chroot and see if the issue persist. neither guile 3 nor libffi7 are present on my system and I do not have any issues.

slondr commented on 2021-11-15 00:56 (UTC)

I found the source of the issue.

libffi7 should be declared as a dependency.

slondr commented on 2021-11-15 00:53 (UTC)

When I try to update to the new version, I get a bunch of errors related to libffi, followed by:

error: found development files for Guile 3.0, but /usr/bin/guile3 has effective version

Is this a known bug?

emacsomancer commented on 2021-10-24 18:27 (UTC) (edited on 2021-10-24 18:27 (UTC) by emacsomancer)

there seemed to be a difference in version for 1.6.8 between the tar.xz and tar.gz sources. In any case, with the update to 1.6.9, the correct version is shown.

dordow commented on 2021-10-24 12:51 (UTC)

Yes, mu -V now shows 1.6.9. I had to restart Emacs because mu4e complained about version mismatch.

mroethke commented on 2021-10-24 12:10 (UTC)

Fixed with 1.6.9

mroethke commented on 2021-10-24 10:35 (UTC)

It seems the tag is on the wrong commit. The one right before bumping the version. So it should probably contain everything it was supposed to, but still reports the old version. I contacted the maintainer. I will fix this myself, if he does not respond soonish.

dordow commented on 2021-10-24 08:47 (UTC)

Yes, confirm, although I have upgraded mu and the PKGBUILD file says 1.6.8.

emacsomancer commented on 2021-10-23 18:23 (UTC)

mu -V still seems to report 1.6.7?

dordow commented on 2021-08-08 11:55 (UTC) (edited on 2021-08-08 11:56 (UTC) by dordow)

Many thanks for these hints. The 'mu4e-view-*' are the culprits indeed. They are still used in BBDB customization, see mu4e manual. I have removed them and it seems that BBDB integration still works, at least auto-completion.

milouse commented on 2021-08-01 15:56 (UTC) (edited on 2021-08-01 15:57 (UTC) by milouse)

@dordow yes with this new release, mu4e now uses gnus as default viewer for the messages. You can either use the following variable to stick with the old view system (setq mu4e-view-use-old t) (however, as it is now deprecated, maybe one day it will be removed?), or try to adopt the new view (like I did). As you, I prefer the text view by default and achieve something good with the following settings:

(setq gnus-inhibit-images t ;; don't include pictures in messages
      ;; Use a custom date/time format in the Date mail header
      gnus-article-date-headers 'user-defined
      gnus-article-time-format "%A %d %B %Y à %R"
      ;; Use specific faces for To and Flags headers to look like the old mu4e view
      gnus-header-face-alist '(("From" nil gnus-header-from)
                               ("Subject" nil gnus-header-subject)
                               ("Newsgroups:.*," nil gnus-header-newsgroups)
                               ("To:" nil gnus-header-from)
                               ("Flags:" nil font-lock-builtin-face)
                               ("" gnus-header-name gnus-header-content))
      ;; Improve default order for headers
      gnus-sorted-header-list '("^From:" "^Reply-To:" "^To:" "^Cc:" "^Subject"
                                "^Date:" "^Flags:")
    ;; Never try to load html version of email by default
    mm-text-html-renderer 'w3m-standalone
    mm-discouraged-alternatives '("text/html"))

If you use the new Gnus message view, you should also check in you own config (.emacs file) that you don't keep old and deprecated variables related to mu4e-view. You must look for all variables beginning by mu4e-view and remove them as they won’t work anymore (I think that’s why you had an error message saying error in process filter: No buffer named mu4e-view: you probably have an old setting trying to do something in mu4e-view, but it is no more there.

dordow commented on 2021-07-31 20:01 (UTC)

OK, it does now format the message without error but as a single line so the message is still unreadable. The same with emacs in command line mode. It looks as if all line breaks are removed. Before migrating, the messages were in text mode (which I prefer), now they seem to be in a somewhat more fancy format

mroethke commented on 2021-07-31 17:11 (UTC)

Maybe it has something to do with this item from the release notes?

*** mu4e

    - Use the gnus-based message viewer as the default; the new viewer has quite
      a few extra features compared to the old, mu4e-specific one, such as
      faster crypto, support for S/MIME, syntax-highlighting, calendar
      invitations and more.

      The new view is superior in most ways, but if you still depend on
      something from the old one, you can use:
      ;; set *before* loading mu4e; and restart emacs if you want to change it
      ;; users of use-packag~ should can use the :init section for this.
      (setq mu4e-view-use-old t)

      (The older variable ~mu4e-view-use-gnus~ with the opposite meaning is
      obsolete now, and no longer in use).

dordow commented on 2021-07-31 16:40 (UTC)

Yes, I did. I have downgraded mu, then mu4e worked as usual. I upgraded again, now it is 1.6.1, run mu init and mu index. but error remains. Any special settings in .emacs I need to consider?

emacsomancer commented on 2021-07-31 15:28 (UTC)

@dordow: did you update mu init ?

call mu init with your preferred parameters (maildir, email addresses), and then call mu index

dordow commented on 2021-07-31 15:05 (UTC)

I use mu with mu4e, and I have trouble with the latest upgrade to 1.6.0. In the message view the message is not formatted, it looks as if it is in raw format, and there is an error message: "error in process filter: No buffer named mu4e-view".

I run mu init, but this did not help. Do I need to adjust any settings in the .emacs file?

I have noticed that a new version of mu is available, 1.6.1.

Thanks in advance

mroethke commented on 2020-07-31 11:10 (UTC)

Nothing to be sorry for :) Thanks for trying to improve this package!

milouse commented on 2020-07-29 17:41 (UTC)

Oh, ok, I didn't know that. Sorry for the noise!

mroethke commented on 2020-07-28 18:56 (UTC)

No, it wont fail. make depends on guile and make is required to be installed on any system that wants to build packages. It probably makes sense to add guile to makedepends though.

milouse commented on 2020-07-28 18:20 (UTC)

Warning, as you made it, the first time someone try to build mu and has never dealt with guile, it will fail as guile is only an optdepends. You must move it to real depends array to ensure it's there.

mroethke commented on 2020-07-28 12:02 (UTC)

I think you are right. Thanks for pointing that out.

milouse commented on 2020-07-27 10:04 (UTC)


I'm wondering if this package really need the double dependence on guile and guile2.0.

As you build it with the --enable-guile switch, I think only guile is required and guile2.0 should be removed. I've just test in on my side with only guile as a dependency: it built fine and doesn't break at runtime… I found no reference to specifically guile2.0 on the upstream project, they always refer to guile 2.x.

pmatos commented on 2020-07-13 13:33 (UTC) (edited on 2020-07-14 08:23 (UTC) by pmatos)

It seems this is being built without encrytion support. Can we please add this?

EDIT: Since 1.4 all version of mu come with encryption support - pls disregard.

mroethke commented on 2020-04-20 09:59 (UTC)


suger commented on 2020-04-19 06:06 (UTC)

Would you mind adding armv7h to the arch line? It builds and works smoothly on this architecture.

mroethke commented on 2019-08-02 09:30 (UTC)

1.3.x is a (quoting from the NEWS file) unreleased, experimental/development version therefore 1.2 is indeed the latest stable release.

mroethke commented on 2019-04-17 14:59 (UTC)

Sure, thank you for pointing that out.

dreieck commented on 2019-04-16 09:41 (UTC)

Can you add make to build(), so that compilation is carried out in build() and not on package()?

Can you move autoreconf -i from build() to prepare()?

mroethke commented on 2019-04-09 11:12 (UTC)

No, emacs is needed to build mu4e.

nac commented on 2019-04-09 01:45 (UTC)

The package builds just fine without emacs as a makedepend. Can you please remove it?

emacsomancer commented on 2019-04-07 19:00 (UTC) (edited on 2019-04-07 19:02 (UTC) by emacsomancer)

# Maintainer:
# Contributor: Pierre Neidhardt <>
# Contributor: csllbr; Popsch <>

pkgdesc="Maildir indexer/searcher and Emacs client (mu4e)"
depends=("gmime3" "xapian-core" "guile2.0")
optdepends=("guile: guile support"
"emacs: mu4e support")

build() { 
   cd "$pkgname-$pkgver"
 autoreconf -i
./configure --prefix=/usr --disable-webkit --disable-gtk --enable-mu4e --enable-guile

package() {
 cd "$pkgname-$pkgver"
 make DESTDIR="$pkgdir" install