Upgraded to 1.5.8-r2 this morning. Afterwards I was checking mail and it wasn't giving it to me. I verified that the mail was on the server and that I was POPing it. After quitting mutt and going back in, the mail was there marked N, when I tried to read or delete, mutt told me the mailbox was read-only, so those new messages were forever N. Downgrading to 1.5.8-r1 cures all ills.
what where the useflags you used?
mail-client/mutt-1.5.8-r2 -buffysize +cjk +crypt -debug +imap +mbox +nls -nntp -sasl +slang +ssl -vanilla
IRC the only change with your useflag-set in -r2 is the assumed_charset patch. try to remove that patch from the ebuild, compile and try it again. unfortunately i can't test it on my own system. i don't have any mailserver with pop3 support.
I'll try it later. I rebooted my home machine for ipsec testing and it didn't come back up. Can't think of why charset changes would make mutt think my mailboxes were read-only.
yes. but at the moment this is the only reason i can imagine. :/
Check http://wiki.mutt.org/index.cgi?MuttFaq/Folder ("I can't read my spool folder, Mutt claims it's read-only, but permissions are ok?") -- this solved the problem for me. For some reason mutt-1.5.8-r2 doesn't install mutt_dotlock with the right owner and setgid permissions...
Now this is really weird. Commenting out line 55 in the 1.5.8-r2 ebuild (the epatch assumed_charset_patch line) results in a mutt_dotlock with proper setgid -- although patch-1.5.6.tt.assumed_charset.1.gz does not seem to contain _anything_ that should have an effect on the Makefile rule that does the chmod 2755 $(DESTDIR)$(bindir)/mutt_dotlock...
Okay, this is rather _really_ weird -- it's not reproducible every time: I did rm /usr/bin/mutt_dotlock \ && emerge =mail-client/mutt-1.5.8-r2 \ && ls -l /usr/bin/mutt_dotlock 10 times while not doing anything else with the system; in five cases it resulted in -rwxr-s--x 1 root mail 35592 Mar 20 18:15 /usr/bin/mutt_dotlock in the other five cases -rwxr-xr-x 1 root root 35592 Mar 20 18:28 /usr/bin/mutt_dotlock Some kind of nasty race condition? Two full emerge outputs with these two results: http://www.schirmeier.com/mutt-1.5.8-r2-merge3 http://www.schirmeier.com/mutt-1.5.8-r2-merge4
That is really weird. This should normally fix the problem. But this is executed on "make install" according to your two emerge-logs. if test -f /var/tmp/portage/mutt-1.5.8-r2/image//usr/bin/mutt_dotlock && test xmail != x ; then \ chgrp mail /var/tmp/portage/mutt-1.5.8-r2/image//usr/bin/mutt_dotlock && \ chmod 2755 /var/tmp/portage/mutt-1.5.8-r2/image//usr/bin/mutt_dotlock || \ { echo "Can't fix mutt_dotlock's permissions!" >&2 ; exit 1 ; } \ fi strange. really strange.
This seems to be due to a buggy upstream Makefile: MAKEOPTS="-j1" instead of "-j2" in my make.conf leads to correct results regarding mutt_dotlock setgid/permissions. I'll check later whether this has already been corrected in 1.5.9 or CVS.
Makefile.am bug spotted, (upstream) patch will follow later tonight.
Created attachment 54097 [details, diff] Makefile.am target correction This patch corrects the install-exec-local target to install-exec-hook which is guaranteed to be executed post-install, even if make is run with -jN with N > 1.
Created attachment 54098 [details, diff] ebuild modification that includes the mutt patch Please consider a version bump.
PS: The patch should be considered to be included in other mutt ebuild versions: - all earlier versions are affected as well - Gentoo users are encouraged to use -j[#CPUs+1] in a make.conf comment It seems to be just luck that this problem hasn't been observed earlier.
My patch has been included in mutt CVS half an hour ago.
Horst, the reason this didn't show up previously is that we don't normally use emake for installation in Gentoo, only compilation. I'm glad that it is now fixed upstream (nice work!) but I'm just reverting the ebuild to use simple make for installation. It was an accident to make that change in the first place.
> Horst, the reason this didn't show up > previously is that we don't normally use > emake for installation in Gentoo, only > compilation. ... > but I'm just reverting the ebuild to use > simple make for installation. It was an > accident to make that change in the first > place. https://bugs.gentoo.org/show_bug.cgi?id=83413#c3 :-P
Yes Octavio
