Re: 1.2.2i problems
On Wed, Jun 21, 2000 at 07:43:23PM -0700, AG wrote: Anyone know why there's such a discrepancy? I think the RPM might be stripping the binaries but I don't know if that would make such a big difference... Doing a mutt -v on both the RPM and manual binaries produces the same output: The spec-helper for Mandrake automagically strips binaries, so this will account for some. Take a look at what spec-helper actually does at the end of %install. Yeah, I was pretty sure that spec-helper stripped the binaries, and I know it compresses manpages and such, but I don't know what else it does. Guess I'll have to pay attention some day and press CTRL-Z when it hits spec-helper... =) Strange thing is the stripped binaries in the RPM versus manually built and stripped binaries still differ in size... any ideas on that one? -- [EMAIL PROTECTED], OpenPGP key available on www.keyserver.net Freezer Burn BBS: telnet://bbs.freezer-burn.org . ICQ: 54924721 Webmaster for the Linux Portal Site Freezer Burn: http://www.freezer-burn.org Current Linux uptime: 2 days 12 hrs and 34 mins.
Re: 1.2.2i problems
Hello Vincent! On Wed, 21 Jun 2000, Vincent Danen wrote: On Wed, Jun 21, 2000 at 03:27:43PM -0400, Bob Bell wrote: Ok... I've still got some problems making my RPM for mutt and I'm not sure what's causing it. I built mutt manually and then I built it with the exact same options for the RPM but I get two totally different outputs. The first is from the manual install and the second is from the RPM install -rwxr-xr-x1 root root 1262377 Jun 21 11:29 /usr/bin/mutt* -rwxr-sr-x1 root mail36607 Jun 21 11:29 /usr/bin/mutt_dotl ^^^ +ock* Thats OK because the 'SGID' flag. [...] But it doesn't look my /var/spool/mail/vdanen file is locked to read-only either after I manually run strip on them. What's about the messages of a 'ls -alF /var' or 'ls -alF /var/spool', especially the group which the directories /var/mail or /var/spool/mail belongs to and it's permissions? bye - Wilhelm -- _____ ___ _ ___ | | (_)_ _ _ ___ __ |_ ) |_ ) / | __| ...solutions for smart penguins | |__| | ' \ || \ \ / / / _ / / _| |__ \ ||_|_||_\_,_/_\_\ /___(_)___(_)_|___/Wilhelm Wienemann
Re: 1.2.2i problems
On Thu, Jun 22, 2000 at 07:58:03AM +0200, Wilhelm Wienemann wrote: Ok... I've still got some problems making my RPM for mutt and I'm not sure what's causing it. I built mutt manually and then I built it with the exact same options for the RPM but I get two totally different outputs. The first is from the manual install and the second is from the RPM install -rwxr-xr-x1 root root 1262377 Jun 21 11:29 /usr/bin/mutt* -rwxr-sr-x1 root mail36607 Jun 21 11:29 /usr/bin/mutt_dotl ^^^ +ock* Thats OK because the 'SGID' flag. Yep, I thought that was the case. But it doesn't look my /var/spool/mail/vdanen file is locked to read-only either after I manually run strip on them. What's about the messages of a 'ls -alF /var' or 'ls -alF /var/spool', especially the group which the directories /var/mail or /var/spool/mail belongs to and it's permissions? All is working 100% now, Wilhelm, thank you. It was a problem with the .spec file for the RPM and now that it's fixed, mutt is rocking over here... =) -- [EMAIL PROTECTED], OpenPGP key available on www.keyserver.net Freezer Burn BBS: telnet://bbs.freezer-burn.org . ICQ: 54924721 Webmaster for the Linux Portal Site Freezer Burn: http://www.freezer-burn.org Current Linux uptime: 2 days 20 hrs and 32 mins.
1.2.2i problems
Ok... I've still got some problems making my RPM for mutt and I'm not sure what's causing it. I built mutt manually and then I built it with the exact same options for the RPM but I get two totally different outputs. The first is from the manual install and the second is from the RPM install -rwxr-xr-x1 root root 1262377 Jun 21 11:29 /usr/bin/mutt* -rwxr-sr-x1 root mail36607 Jun 21 11:29 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:29 /usr/bin/muttbug* -rwxr-xr-x1 root root 418000 Jun 21 11:24 /usr/bin/mutt* -rwxr-sr-x1 root root 7588 Jun 21 11:24 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:23 /usr/bin/muttbug* Anyone know why there's such a discrepancy? I think the RPM might be stripping the binaries but I don't know if that would make such a big difference... Doing a mutt -v on both the RPM and manual binaries produces the same output: Mutt 1.2.2i (2000-06-21) Copyright (C) 1996-2000 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 2.2.15-4mdk [using slang 10400] Compile options: -DOMAIN -DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_IMAP -USE_GSS -USE_SSL +USE_POP +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_PGP -BUFFY_SIZE -EXACT_ADDRESS +ENABLE_NLS SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/spool/mail" SHAREDIR="/etc" SYSCONFDIR="/etc" ISPELL="/usr/bin/ispell" To contact the developers, please mail to [EMAIL PROTECTED]. To report a bug, please use the muttbug utility. I also still have a problem with colors, regardless of which binary I use. My color config looks like: # # color definitions # # if you (TERM=xterm-color; export TERM) you get color: color normal white default color hdrdefault brightwhite default color quoted brightblue default color signature white default color indicator brightyellow default color error brightred default color status yellow blue color tree brightblue default # the thread tree in the index menu color tilde magenta default color message brightcyan default color markers brightcyan default color attachment brightmagenta default color search default brightgreen# how to hilite search patterns in the pager color header brightgreen default ^(From|Subject|To): color body brightcyan default "(ftp|http)://[^ ]+" # point out URLs color body brightcyan default [-a-z_0-9.]+@[-a-z_0-9.]+ # e-mail addresses color underline brightwhite default When I comment it all out, then I get mono but I can see what I'm doing. Otherwise the colors are severely messed up. Any ideas about this one? The one thing I like about mutt is the color support, but it kinda needs to work too... =( Any and all help is appreciated. -- [EMAIL PROTECTED], OpenPGP key available on www.keyserver.net Freezer Burn BBS: telnet://bbs.freezer-burn.org . ICQ: 54924721 Webmaster for the Linux Portal Site Freezer Burn: http://www.freezer-burn.org
Re: 1.2.2i problems
On Wed, Jun 21, 2000 at 11:34:45AM -0600, Vincent Danen [EMAIL PROTECTED] wrote: Ok... I've still got some problems making my RPM for mutt and I'm not sure what's causing it. I built mutt manually and then I built it with the exact same options for the RPM but I get two totally different outputs. The first is from the manual install and the second is from the RPM install -rwxr-xr-x1 root root 1262377 Jun 21 11:29 /usr/bin/mutt* -rwxr-sr-x1 root mail36607 Jun 21 11:29 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:29 /usr/bin/muttbug* -rwxr-xr-x1 root root 418000 Jun 21 11:24 /usr/bin/mutt* -rwxr-sr-x1 root root 7588 Jun 21 11:24 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:23 /usr/bin/muttbug* Anyone know why there's such a discrepancy? I think the RPM might be stripping the binaries but I don't know if that would make such a big difference... Doing a mutt -v on both the RPM and manual binaries produces the same output: Quite possibly. What happens when you run `strip` on the first set of files? -- Bob BellCompaq Computer Corporation Software Engineer 110 Spit Brook Rd - ZKO3-3/U14 TruCluster GroupNashua, NH 03062-2698 [EMAIL PROTECTED] 603-884-0595
Re: 1.2.2i problems
On Wed, Jun 21, 2000 at 11:34:45AM -0600, Vincent Danen wrote: -rwxr-xr-x1 root root 1262377 Jun 21 11:29 /usr/bin/mutt* -rwxr-sr-x1 root mail36607 Jun 21 11:29 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:29 /usr/bin/muttbug* -rwxr-xr-x1 root root 418000 Jun 21 11:24 /usr/bin/mutt* -rwxr-sr-x1 root root 7588 Jun 21 11:24 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:23 /usr/bin/muttbug* Anyone know why there's such a discrepancy? I think the RPM might be stripping the binaries but I don't know if that would make such a big difference... I think it could. Try to strip your binaries and look at their sizes then. (That's only 3x difference, C++ programs may decrease in size ten times after stripping.) System: Linux 2.2.15-4mdk [using slang 10400] I also still have a problem with colors, regardless of which binary I use. My color config looks like: [...] When I comment it all out, then I get mono but I can see what I'm doing. Otherwise the colors are severely messed up. Any ideas about this one? The one thing I like about mutt is the color support, but it kinda needs to work too... =( This is Unix. Extreme flexibility and many possible points of failure. Your terminal program could be buggy. It could have different RGB values assigned to colour numbers. Its terminfo description may be wrong (e.g. earlier versions of Eterm specified setf=/setb= instead of setaf=/setab=). Your $TERM may not match your terminal program (all those xterm clones usually are different in this regard, and xterm itself has many versions.) This might be a bug in slang/ncurses (even the latest stable ncurses version (5.0) is buggy). This might be a bug in Mutt (unlikely). Several of the above may be true. I've had *lots* and *lots* of problems with Mutt and colours. All investigations and lots of time spent debugging them showed that the problems weren't Mutt's fault. I finally fixed my terminfo and settled on ncurses 5.0, since it distored my colours less than slang or other ncurses versions. YMMV. (I've been told that latest ncurses developement versions have my problem fixed. I still haven't tried them...) Marius Gedminas -- If it wasn't for C, we'd be using BASI, PASAL and OBOL
Re: 1.2.2i problems
On Wed, Jun 21, 2000 at 11:34:45AM -0600, Vincent Danen [EMAIL PROTECTED] wrote: Ok... I've still got some problems making my RPM for mutt and I'm not sure what's causing it. I built mutt manually and then I built it with the exact same options for the RPM but I get two totally different outputs. The first is from the manual install and the second is from the RPM install -rwxr-xr-x1 root root 1262377 Jun 21 11:29 /usr/bin/mutt* -rwxr-sr-x1 root mail36607 Jun 21 11:29 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:29 /usr/bin/muttbug* -rwxr-xr-x1 root root 418000 Jun 21 11:24 /usr/bin/mutt* -rwxr-sr-x1 root root 7588 Jun 21 11:24 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:23 /usr/bin/muttbug* Anyone know why there's such a discrepancy? I think the RPM might be stripping the binaries but I don't know if that would make such a big difference... Doing a mutt -v on both the RPM and manual binaries produces the same output: Is it possible that the first group is statically linked, and the second is dynamically linked? Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: 1.2.2i problems
On Wed, 21 Jun 2000, Marius Gedminas wrote: I've had *lots* and *lots* of problems with Mutt and colours. All investigations and lots of time spent debugging them showed that the problems weren't Mutt's fault. I finally fixed my terminfo and settled on ncurses 5.0, since it distored my colours less than slang or other ncurses versions. YMMV. (I've been told that latest ncurses developement versions have my problem fixed. I still haven't tried them...) As I noted, the last bug that you reported I found to be in mutt rather than ncurses (the one where bold attributes are displayed in the status lines). Of course there are other bugs in ncurses (I have a partial list). -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: 1.2.2i problems
On 2000-06-21 14:11:05 -0600, Charles Cazabon wrote: -rwxr-xr-x1 root root 1262377 Jun 21 11:29 /usr/bin/mutt* -rwxr-sr-x1 root mail36607 Jun 21 11:29 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:29 /usr/bin/muttbug* -rwxr-xr-x1 root root 418000 Jun 21 11:24 /usr/bin/mutt* -rwxr-sr-x1 root root 7588 Jun 21 11:24 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:23 /usr/bin/muttbug* Is it possible that the first group is statically linked, and the second is dynamically linked? I'd guess stripped vs. non-stripped including debugging info.
Re: 1.2.2i problems
At 1:34 PM EDT on June 21 Vincent Danen sent off: Ok... I've still got some problems making my RPM for mutt and I'm not sure what's causing it. I built mutt manually and then I built it with the exact same options for the RPM but I get two totally different outputs. The first is from the manual install and the second is from the RPM install -rwxr-xr-x1 root root 1262377 Jun 21 11:29 /usr/bin/mutt* -rwxr-sr-x1 root mail36607 Jun 21 11:29 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:29 /usr/bin/muttbug* -rwxr-xr-x1 root root 418000 Jun 21 11:24 /usr/bin/mutt* -rwxr-sr-x1 root root 7588 Jun 21 11:24 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:23 /usr/bin/muttbug* Anyone know why there's such a discrepancy? I think the RPM might be stripping the binaries but I don't know if that would make such a big difference... Doing a mutt -v on both the RPM and manual binaries produces the same output: It must be either not stripped and/or statically linked, and the quickest way to check is file, i.e. file /usr/bin/mutt -- "Men never do evil so completely and cheerfully as when they do it with religious conviction." - Blaise Pascal (1623-1662), Thoughts, #894 Robert I. Reid [EMAIL PROTECTED] http://astro.utoronto.ca/~reid/ PGP Key: http://astro.utoronto.ca/~reid/pgp.html
Re: 1.2.2i problems
On Wed, Jun 21, 2000 at 03:35:42PM -0400, Rob Reid wrote: Ok... I've still got some problems making my RPM for mutt and I'm not sure what's causing it. I built mutt manually and then I built it with the exact same options for the RPM but I get two totally different outputs. The first is from the manual install and the second is from the RPM install -rwxr-xr-x1 root root 1262377 Jun 21 11:29 /usr/bin/mutt* -rwxr-sr-x1 root mail36607 Jun 21 11:29 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:29 /usr/bin/muttbug* -rwxr-xr-x1 root root 418000 Jun 21 11:24 /usr/bin/mutt* -rwxr-sr-x1 root root 7588 Jun 21 11:24 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:23 /usr/bin/muttbug* Anyone know why there's such a discrepancy? I think the RPM might be stripping the binaries but I don't know if that would make such a big difference... Doing a mutt -v on both the RPM and manual binaries produces the same output: It must be either not stripped and/or statically linked, and the quickest way to check is file, i.e. file /usr/bin/mutt Ok, I ran it on both a manually stripped, manually built mutt and then the RPMized mutt and they both say the same thing: /usr/bin/mutt: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped That looks ok to me, but both sizes are slightly different when I manually-build/manually-strip as opposed to the RPM version (see other message for exact sizes). -- [EMAIL PROTECTED], OpenPGP key available on www.keyserver.net Freezer Burn BBS: telnet://bbs.freezer-burn.org . ICQ: 54924721 Webmaster for the Linux Portal Site Freezer Burn: http://www.freezer-burn.org Current Linux uptime: 2 days 5 hrs and 00 mins.
Re: 1.2.2i problems
On Wed, Jun 21, 2000 at 09:45:22PM +0200, Marius Gedminas wrote: -rwxr-xr-x1 root root 1262377 Jun 21 11:29 /usr/bin/mutt* -rwxr-sr-x1 root mail36607 Jun 21 11:29 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:29 /usr/bin/muttbug* -rwxr-xr-x1 root root 418000 Jun 21 11:24 /usr/bin/mutt* -rwxr-sr-x1 root root 7588 Jun 21 11:24 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:23 /usr/bin/muttbug* Anyone know why there's such a discrepancy? I think the RPM might be stripping the binaries but I don't know if that would make such a big difference... I think it could. Try to strip your binaries and look at their sizes then. (That's only 3x difference, C++ programs may decrease in size ten times after stripping.) Yup, tried that (see other message for the sizes). They're still slightly different between the manual and RPM compiles. System: Linux 2.2.15-4mdk [using slang 10400] I also still have a problem with colors, regardless of which binary I use. My color config looks like: [...] When I comment it all out, then I get mono but I can see what I'm doing. Otherwise the colors are severely messed up. Any ideas about this one? The one thing I like about mutt is the color support, but it kinda needs to work too... =( This is Unix. Extreme flexibility and many possible points of failure. Your terminal program could be buggy. It could have different RGB values assigned to colour numbers. Its terminfo description may be wrong (e.g. earlier versions of Eterm specified setf=/setb= instead of setaf=/setab=). Your $TERM may not match your terminal program (all those xterm clones usually are different in this regard, and xterm itself has many versions.) This might be a bug in slang/ncurses (even the latest stable ncurses version (5.0) is buggy). This might be a bug in Mutt (unlikely). Several of the above may be true. Yeah, but I'm using this in the console (no Eterm/xterm stuff), and it worked with mutt 1.0.1. I'm assuming that it dynamically uses the slang stuff, or is it statically included? I think that the 1.0.1 mutt was compiled with an older version of slang while the new mutt was compiled with a newer slang. I haven't tried it with ncurses, however, so I might try that out. I've had *lots* and *lots* of problems with Mutt and colours. All investigations and lots of time spent debugging them showed that the problems weren't Mutt's fault. I finally fixed my terminfo and settled on ncurses 5.0, since it distored my colours less than slang or other ncurses versions. YMMV. (I've been told that latest ncurses developement versions have my problem fixed. I still haven't tried them...) Hmmm... I'll try it with ncurses and we'll see if that makes any difference. I just found it wierd that with mutt 1.0.1 the color worked awesome (also compiled with slang) yet with 1.2.2 it's really whacked out. But we'll see if ncurses makes a difference. -- [EMAIL PROTECTED], OpenPGP key available on www.keyserver.net Freezer Burn BBS: telnet://bbs.freezer-burn.org . ICQ: 54924721 Webmaster for the Linux Portal Site Freezer Burn: http://www.freezer-burn.org Current Linux uptime: 2 days 5 hrs and 02 mins.
Re: 1.2.2i problems
On Wed, Jun 21, 2000 at 02:11:05PM -0600, Charles Cazabon wrote: Ok... I've still got some problems making my RPM for mutt and I'm not sure what's causing it. I built mutt manually and then I built it with the exact same options for the RPM but I get two totally different outputs. The first is from the manual install and the second is from the RPM install -rwxr-xr-x1 root root 1262377 Jun 21 11:29 /usr/bin/mutt* -rwxr-sr-x1 root mail36607 Jun 21 11:29 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:29 /usr/bin/muttbug* -rwxr-xr-x1 root root 418000 Jun 21 11:24 /usr/bin/mutt* -rwxr-sr-x1 root root 7588 Jun 21 11:24 /usr/bin/mutt_dotlock* -rwxr-xr-x1 root root 6668 Jun 21 11:23 /usr/bin/muttbug* Anyone know why there's such a discrepancy? I think the RPM might be stripping the binaries but I don't know if that would make such a big difference... Doing a mutt -v on both the RPM and manual binaries produces the same output: Is it possible that the first group is statically linked, and the second is dynamically linked? Nope, they're both dynamic. One is stripped and the other isn't. -- [EMAIL PROTECTED], OpenPGP key available on www.keyserver.net Freezer Burn BBS: telnet://bbs.freezer-burn.org . ICQ: 54924721 Webmaster for the Linux Portal Site Freezer Burn: http://www.freezer-burn.org Current Linux uptime: 2 days 5 hrs and 06 mins.
Re: 1.2.2i problems
On Wed, 21 Jun 2000, Vincent Danen wrote: Anyone know why there's such a discrepancy? I think the RPM might be stripping the binaries but I don't know if that would make such a big difference... Doing a mutt -v on both the RPM and manual binaries produces the same output: The spec-helper for Mandrake automagically strips binaries, so this will account for some. Take a look at what spec-helper actually does at the end of %install. -- _ _|_|_ ( ) *Anton Graham /v\ / [EMAIL PROTECTED] /( )X (m_m) GPG ID: 18F78541 Penguin Powered!
