Re: Release-critical Bugreport for March 18, 2000
On Sat, Mar 18, 2000 at 09:46:25AM -0600, BugScan reporter wrote: > Package: communicator (debian/contrib) > Maintainer: Adam Heath <[EMAIL PROTECTED]> > 60193 communicator: buss error when replying to message Communicator is a meta package. This bug should be reassigned to the version of netscape which crashes. > Package: lsof (debian/main) > Maintainer: Jim Mintha <[EMAIL PROTECTED]> > 57203 lsof does not build with 2.3 kernel headers [EMAIL PROTECTED]: Log > for failed build of lsof_4.48-1 (dist=frozen)] Should this be release-critical? Don't we ship 2.2 headers by default? If this can't be fixed easily, it might be acceptable to downgrade it. > Package: mozilla (debian/main) > Maintainer: Debian Mozilla maintainers <[EMAIL PROTECTED]> > 60589 mozilla: Mozilla M14 crashes with a segmentation fault error > 60596 mozilla: Segfault May be caused by old ~/.mozilla directory. > Package: netscape (debian/contrib) > Maintainer: Adam Heath <[EMAIL PROTECTED]> > 60619 netscape: Error message: 'Bus error' when trying to run netscape. As above - meta package. Is Adam MIA? If so, can we get someone to either fix the bugs which can be fixed (such as the packaging bugs) and make a decision as to whether Netscape 4.72 is too buggy to ship? IMO, at least one version of Netscape should be included in potato. Yes, it sucks and is non-free, but it's expected of a "real" distribution. People have come to accept its suckage, and as such crashing bugs (which we can't fix) should be downgraded to normal IMO. The least buggy version of Netscape should be shipped - lesser of >2 evils. Mozilla isn't an option, yet, not for the average user and not for me (because it chews up more memory than Netscape. I use it but not often because of the thrashing).
Re: Single architecture on -announce lists
In article <[EMAIL PROTECTED]> you wrote: > It might be he wants to talk about -changes ? There he's right (and I do > totally agree with him). I'm not excited about a list per architecture, but I've often wondered if only posting to the lists messages for uploads that include source might not be the right thing... the lists of things uploaded from the autobuilders aren't particularly interesting, which seeing the changelogs for each new source upload are. Bdale
Re: ITP: xzgv
On Mar 17, Andreas Tille wrote: > On Sun, 6 Feb 2000, David Starner wrote: > > Honestly, I found the interface of ImageMagick to be too clumsy > > to just view pictures. Until I grabbed xzgv out of Incoming, > > xv was the least clumsy graphic viewer interface. The authors > > of xzgv have produced an X viewer that I can be happy with. > There was a long time since this ITP. Do you still plan to package > it? Unfortunately I didn't found it in the list of GTK+ > applications under www.gtk.org to have a look at it. Eh? xzgv has been in woody for at least 3 weeks. Chris -- = | Chris Lawrence | Your source for almost nothing of value: | | <[EMAIL PROTECTED]> | http://www.lordsutch.com/ | || | |Open Directory Editor |Your site belongs here. | | http://dmoz.org/ |[Commercialize your sig today!] | =
Re: Single architecture on -announce lists
Tom Lees <[EMAIL PROTECTED]> wrote: > On Sat, Mar 18, 2000 at 05:30:41PM +0100, Paul Seelig wrote: > > Currently i've subscribed to devel-changes on another mail account which > > only serves for sorting out the relevant (at least for me) parts. These > > are sorted out using procmail (which is not supported by my usual mail > > server) and are forwarded this way to my usual mail account, dropping the > > rest (IMHO the major part) into the bit bucket. > > Could you possibly post/email me your procmail recipes to do this? There are a set of rules for handling this that come with devscripts. Install devscripts and have a look in /usr/share/doc/devscripts/examples/ -- while :;do read x;echo \?;done
Re: xfs question
On Fri, Mar 17, 2000 at 09:41:49PM +0100, Michael Meskes wrote: > I see. Thanks. I tried unix/localhost:7100 and that doesn't work. remove that 'localhost' and you are on! Bye, Matthias -- +-created at Sun Mar 19 10:59:46 CET 2000-+ |Matthias Berse Phone:+49-2323-42397 | \Bachstr.28 44625 Herne, GermanyeMail: [EMAIL PROTECTED]/ We all know that no one understands anything that isn't funny.
Re: Release-critical Bugreport for March 18, 2000
On Sat, Mar 18, 2000 at 07:05:23PM -0500, Joe Drew wrote: > > Package: lsof (debian/main) > > Maintainer: Jim Mintha <[EMAIL PROTECTED]> > > 57203 lsof does not build with 2.3 kernel headers [EMAIL PROTECTED]: Log > > for failed build of lsof_4.48-1 (dist=frozen)] > > Should this be release-critical? Don't we ship 2.2 headers by default? > If this can't be fixed easily, it might be acceptable to downgrade it. Even if it is easily fixable I think this cannot be release-critical. Anyone objects a downgrade? Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
/etc/shadow world-readable
hi, i just realized that /etc/shadow are mode 644 (owned by root:root) on two of my systems. (Another two machines are not affected, however) i'm sure this change was not made manually, but have no clue what could have caused it. a grep in /var/lib/dpkg/info didn't show anything. anyone got this, too? machines are: 1. old potato machine (routing+filtering, proxy, afbackup)[not affected] 2. newer, but not up-to-date potato machine (apache, qmail, with shellaccouts for users)[AFFECTED] 3. up-to-date potato machine (routing, samba+proftp fileserver) [not affected] 4. up-to-date woody machine (personal workstation, X, gnome, devel) [AFFECTED] the only thing i realise these machines have in common: machines 1+3 are mainly accessed with ssh-rsa keys and are using pam_unix for other authenication, 2+4 use pam_pwdb and are frequently accessed without rsa-keys but i could not reproduce the problem so far any ideas? -- CU, / Friedrich-Alexander University Erlangen, Germany Martin Waitz// [Tali on IRCnet] [tali.home.pages.de] _ __/// - - - - - - - - - - - - - - - - - - - - /// dies ist eine manuell generierte mail, sie beinhaltet// tippfehler und ist auch ohne grossbuchstaben gueltig. / pgp6YoHFgp3aD.pgp Description: PGP signature
Re: Release-critical Bugreport for March 18, 2000
-BEGIN PGP SIGNED MESSAGE- BugScan reporter writes: > Package: tetex-base (debian/main) > Maintainer: teTeX maintainers <[EMAIL PROTECTED]> > 42698 tetex-base: The french option of babel is broken > > Package: tetex-bin (debian/main) > Maintainer: teTeX maintainers <[EMAIL PROTECTED]> > [HELP] Christoph has set up a mailing list [EMAIL PROTECTED] > to discuss work on these packages. > 36671 tetex-bin: xdvi fails on gzipped files > Fixes are available. I just included them and I am testing now. There will be uploads in the next hours. People are wellcome to join the tetex-maint list. We could need some more help with evaluating bug reports, providing patches and testing. Especially the issues, what should be done for the potato release, have to be discussed. Christoph -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Comment: Processed by Mailcrypt 3.5.1, an Emacs/PGP interface Charset: noconv iQEVAwUBONS//G4/9k35XC9tAQH8twf/SZG/l0JF2wmrqPGyhlgi1JXHvR1LUyAp 3l2Vek78a7OTOZhjfYa2rfVrmwjfeZ+S3R5oJUWJgsFKLna3n8zUxngHrBUNWJFy CPOa78ZG21fu+dzcZoDloAvx6rJbJvkwZP1dMTqMN78eeHair7BrmNSUcNGKRgJv +ilt5IBkbyuiUZgSdSLjvezNJTeU9wSPVmy8GAxv2ryiEj+8Z79+lMHAUa6DZ2hf rMenQSC7wsKForG5fzXYTHxlew2MnGjWIPVA/1rIYKVNWGWMfHbw3ySMCNK1rZqo vIpvRXZhZvM/Kks5Pcy71tv9ud/TqvGDt6HPJeBP3eAUBkZMN84Tng== =gfNS -END PGP SIGNATURE-
Intent to Package: abook
I intend to package abook (an ncurses address book program): http://www.linuxstart.com/~jheinonen/abook/ License is GPL. I have the package ready. This package is being sponsored by Edward Betts <[EMAIL PROTECTED]> -- Alan Ford <[EMAIL PROTECTED]>
Intent to Package: Selection of Perl/Tk Net Utils
I have packaged my selection of Perl/Tk network utils, from: http://www.whirlnet.co.uk/linux/ All are under GPL. I've had a package of these sitting around since June, waiting for new-maintainer to re-open, but now I've become fed up of waiting and this is being sponsored by Edward Betts <[EMAIL PROTECTED]> -- Alan Ford <[EMAIL PROTECTED]>
ITP: solfege
Solfege is an eartraining program for GNOME written in python. (http://solfege.sourceforge.net) I'm the author of the program and Olav Stetzer will be sponsoring me. The package will be called solfege Tom Cato Amundsen
Re: aptitude
Previously Jacob Kuntz wrote: > Robert Ramiega ([EMAIL PROTECTED]) wrote: > > I must have missed it... Anyway it needs dpkg.h and i cant find it on my > > system... Searcher on Debian Web site can't find it either =o(( > > it's in dpkg-dev. It used to be, but I remove libdpkg and its header-files from dpkg-dev a while ago: they were only written as a way to share code between dpkg and dselect and were never intended to be used for something else. They should never have been in dpkg-dev. Unfortunately the Stormix people weren't aware of that and used libdpkg in the frontend. At the moment they're converting it to use libapt-pkg though and from what I hear they're making nice progress with that. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpTLViRTFHWE.pgp Description: PGP signature
new Debian tetex versions - please test
-BEGIN PGP SIGNED MESSAGE- Hi there, I have put some new version of tetex-* for potato in ftp.uni-mainz.de/pub/Linux/debian-local for testing. Please test them for the fixed bugs and let me know if there are further issues. from the changelogs: tetex-bin (1.0.6-4) frozen unstable; urgency=medium * fmtutil,texconfig,texlinks,texdoc return error code now correctly (closes: Bug#35884) * texdoc can now view compressed documentation (closes: Bug#44279) * xdvi (xdvi-sh) can now display compressed .dvi files (closes: Bug#36671) * texconfig searches now in /usr/share/doc/texmf for FAQ * register dvips.info (closes: Bug#56818) tetex-base (1.0-8) frozen unstable; urgency=medium * fixed broken french option in babel (closes: Bug#42698) * remove ^Z from picins.sty (closes: Bug#42938) Christoph -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Comment: Processed by Mailcrypt 3.5.1, an Emacs/PGP interface Charset: noconv iQEVAwUBONTvom4/9k35XC9tAQGFVgf+LVw8wA05dzZtylJrHeHAgysIO91fuUF9 JZTu/9dvPX5NKA4R7VvTbYMC0xtzv/8v4+VRECPLB5g7PY4ZQ4bX1prBZ0er5ei6 IYvO00b6QnqvCckawviQNHjupz3lQB4cthGrnTYKLbwvhOmPSVrJwZk3pHO4LlF8 ePbb9c9D4/5+YBfMtsjNhBHJaGbTvquDAzdwzuElYfgKjK8Dx96MjwxakhLH5ykq Yb3rBEWd9Fgs+BjfgKDUZJNPqFXCJ6nWKKTOy12d9fkJ9QiE8WXZUDN29JIP0E/9 NfBQUn7oj2+W6sI9/g/sczjnE16FFM6p4xLlJX7/1VTzmt776zmJHA== =sdIU -END PGP SIGNATURE-
Re: Single architecture on -announce lists
Previously Zed Pobre wrote:
> It's a fairly common ruleset, I think. You can have mine.
That can be done a lot simpler:
:0:
* ^X-Mailing-List:.*debian-devel-changes
{
:0
* ^Subject:.*\((alpha|arm|powerpc|m68k|sparc)\)
/dev/null
:0
debian-devel-changes/
}
Wichert.
--
/ Generally uninteresting signature - ignore at your convenience \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
pgpnbl3N9l1zG.pgp
Description: PGP signature
Re: Single architecture on -announce lists
On Fri, Mar 17, 2000 at 04:49:54PM -0500, Bob Hilliard wrote: > During the slink freeze there was some discussion of the wasted > bandwidth due to -devel-announce and -announce listing all packages > installed/uploaded to all architectures. > > As I recall, the consensus was that, after slink was released, > these lists would be split by architecture, and anyone interested in > more than one architecture could subscribe to as many lists as > required. I am sure that the overwhelming majority would subscribe to > only one list. [EMAIL PROTECTED](11:01am)-/var/list]%ls -d debian-*-changes debian-all-changes/ debian-devel-changes/ debian-hurd-i386-changes/ debian-alpha-changes/debian-devel-hurd-i386-changes/ debian-i386-changes/ debian-arm-changes/ debian-devel-i386-changes/ debian-m68k-changes/ debian-devel-all-changes/debian-devel-m68k-changes/ debian-powerpc-changes/ debian-devel-alpha-changes/ debian-devel-powerpc-changes/ debian-sparc-changes/ debian-devel-arm-changes/debian-devel-sparc-changes/ The lists already exist, they are just not used at all. Maybe it would be easier to keep just the one debian-devel-changes list to send to and write some extra procmail stuff into sending it to the write outlist. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
hwtools going multiarch (for scsi stuff)
Hello Siggy, It seems your are the new maintainer of hwtools. Good :-)) I sent few weeks ago a request to enhance hwtools for multiarch support (#58060). In fact, I'm willing to use the scsi stuff on my sparc too (especially scsiinfo & scsidev). I succedeed to using it with really minor fixes. On this topic, yesterday I discovered a new release of scsidev (2.10) made by Kurt Garloff <[EMAIL PROTECTED]> (http://www.garloff.de/kurt/linux/scsidev/). I also took a look at the BTS against this package and saw several bugs reported against scsidev. I guess this release fixes them. If you don't want to work on it, I can do the following work: - add support for non-i386 arch (scsi stuff only; other tools seem to be really i386 specific) - upgrade scsidev and write support for running it at boot time. However, instead of moving hwtools multi-arch it could be better to split the scsi part out of it and create a new scsitools package (I can adopt it if you want). What do you think about this? Regards. -- Eric Delaunay | S'il n'y a pas de solution, c'est qu'il n'y [EMAIL PROTECTED] | a pas de problème. Devise Shadok.
Re: Single architecture on -announce lists
Ben Collins wrote: > > As I recall, the consensus was that, after slink was released, > > these lists would be split by architecture, and anyone interested in > > more than one architecture could subscribe to as many lists as > > required. I am sure that the overwhelming majority would subscribe to > > only one list. > > [EMAIL PROTECTED](11:01am)-/var/list]%ls -d debian-*-changes > debian-all-changes/ debian-devel-changes/ > debian-hurd-i386-changes/ > debian-alpha-changes/debian-devel-hurd-i386-changes/ > debian-i386-changes/ > debian-arm-changes/ debian-devel-i386-changes/ > debian-m68k-changes/ > debian-devel-all-changes/debian-devel-m68k-changes/ > debian-powerpc-changes/ > debian-devel-alpha-changes/ debian-devel-powerpc-changes/ > debian-sparc-changes/ > debian-devel-arm-changes/debian-devel-sparc-changes/ Hm, it's a shame that doesn't include a debian-devel-source-changes, the only -changes list I'm interested in. :-( > The lists already exist, they are just not used at all. Maybe it would be > easier to keep just the one debian-devel-changes list to send to and write > some extra procmail stuff into sending it to the write outlist. Well, we could just sign everyone who is currently subscribed to debian-devel-changes up to debian-devel-*-changes, and obsolete debian-devel-changes. Then post an announcement that people can easily selectively filter mail by unsubscribing from architectures they're not interested in. Although I guess that might mess with some people's mail filters, to change list names behind their backs.. Oh, you mean those lists are dead, not that no-one is subscribed. Should be easy enough to fix though, now that 99.9% of all announcements go via dinstall. IIRC last time this came up we mostly put a fix on hold until dinstall could be modified to send announcements. -- see shy jo
Re: Single architecture on -announce lists
Ben Collins <[EMAIL PROTECTED]> writes: > On Fri, Mar 17, 2000 at 04:49:54PM -0500, Bob Hilliard wrote: > > During the slink freeze there was some discussion of the wasted > > bandwidth due to -devel-announce and -announce listing all packages > > installed/uploaded to all architectures. > > > > As I recall, the consensus was that, after slink was released, > > these lists would be split by architecture, and anyone interested in > > more than one architecture could subscribe to as many lists as > > required. I am sure that the overwhelming majority would subscribe to > > only one list. > > [EMAIL PROTECTED](11:01am)-/var/list]%ls -d debian-*-changes > debian-all-changes/ debian-devel-changes/ > debian-hurd-i386-changes/ > debian-alpha-changes/debian-devel-hurd-i386-changes/ > debian-i386-changes/ > debian-arm-changes/ debian-devel-i386-changes/ > debian-m68k-changes/ > debian-devel-all-changes/debian-devel-m68k-changes/ > debian-powerpc-changes/ > debian-devel-alpha-changes/ debian-devel-powerpc-changes/ > debian-sparc-changes/ > debian-devel-arm-changes/debian-devel-sparc-changes/ > > The lists already exist, they are just not used at all. Maybe it would be > easier to keep just the one debian-devel-changes list to send to and write > some extra procmail stuff into sending it to the write outlist. That was what I understood was the intention last year. Apparently the listmasters created the lists, but no one set up the scripts or procmail stuff to implement it. Is it the listmasters responsibility to set this up, or does it belong to admin? I would certainly like to see it happen. Bob -- _ |_) _ |_ Robert D. Hilliard<[EMAIL PROTECTED]> |_) (_) |_) Palm City, FL USAPGP Key ID: A8E40EB9
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
close 60750 close 60753 thanks On Mar 19, [EMAIL PROTECTED] wrote: >The /etc/Muttrc in the mutt package makes a fruit salad of mutt. Most people like it. >When using mutt in an xterm, the color bindings in /etc/Muttrc make it >very hard to read mail: 8 different colors on one screen, colored text >on white background in the message but colored text on black background >in the headers, it's just horrible. You are doing something wrong, that does not happens with the default configuration. I think you have some color lines in your ~/.muttrc. I had to experiment a long time to have settings which works fine both in xterms and console, and I'm not going to change the default Muttrc without a very good reason. >For an example why I think this is really a bug with severity normal, and >not a wish or feature request, see >http://duckman.blub.net/~wouter/muttdefaults.png Seen. My xterms are *very* different, even with a white background. -- ciao, Marco
Re: Bug#60399: crashes on installation
> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes: Ben> try running: Ben> dpkg-deb --extract man.deb /tmp/tmpdir Ben> If that fails too, then add "strace -o dpkg-deb.out" to the Ben> start of that line and send me the dpkg-deb.out file. No errors: lyell:~# dpkg-deb --extract /var/cache/apt/archives/man-db_2.3.14_i386.deb /tmp/abc lyell:~# echo $? only crashes when upgrading from 2.3.13 to 2.3.14 with apt-get: Hang on, it worked this time. Oh well... LATER: ARghghhh!!! It only happens (I think) when "Building manual page index in background." is still running from the previous installation: lyell:~# dpkg -i /var/cache/apt/archives/man-db_2.3.13_i386.deb dpkg - warning: downgrading man-db from 2.3.14 to 2.3.13. (Reading database ... 55565 files and directories currently installed.) Preparing to replace man-db 2.3.14 (using .../man-db_2.3.13_i386.deb) ... Removing catpages as well as /var/cache/man hierarchy. Unpacking replacement man-db ... Setting up man-db (2.3.13) ... Building manual page index in background. lyell:~# apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages have been kept back openldapd 1 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded. Need to get 0B/332kB of archives. After unpacking 0B will be used. Do you want to continue? [Y/n] y (Reading database ... 55565 files and directories currently installed.) Preparing to replace man-db 2.3.13 (using .../man-db_2.3.14_i386.deb) ... Removing catpages as well as /var/cache/man hierarchy. Unpacking replacement man-db ... dpkg-deb: subprocess paste killed by signal (Broken pipe) dpkg: error processing /var/cache/apt/archives/man-db_2.3.14_i386.deb (--unpack): subprocess dpkg-deb --fsys-tarfile returned error exit status 2 Building manual page index in background. Errors were encountered while processing: /var/cache/apt/archives/man-db_2.3.14_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) If I wait for the first installation to complete in the background, then it works. Looks like a race condition or something here... However, this still doesn't explain why my initial installation of man-db failed... So, lets try something else: lyell:~# dpkg -i /var/cache/apt/archives/man-db_2.3.14_i386.deb (Reading database ... 55565 files and directories currently installed.) Preparing to replace man-db 2.3.13 (using .../man-db_2.3.14_i386.deb) ... Document `man-db' is not installed, cannot remove. Removing catpages as well as /var/cache/man hierarchy. Unpacking replacement man-db ... dpkg-deb: subprocess paste killed by signal (Broken pipe) dpkg: error processing /var/cache/apt/archives/man-db_2.3.14_i386.deb (--install): subprocess dpkg-deb --fsys-tarfile returned error exit status 2 Building manual page index in background. Errors were encountered while processing: /var/cache/apt/archives/man-db_2.3.14_i386.deb now it wont install at all for me, even when man-db isn' running in the background. Something really weird here. this still works: lyell:~# dpkg-deb --extract /var/cache/apt/archives/man-db_2.3.14_i386.deb /tmp/abc running dpkg -i under strace fills up my hard-disk, but also works, too. only seems to crash when upgrading 2.3.13 to 2.3.14. I cannot reproduce it for 2.3.14 to 2.3.14 (although I suspect having two copies of mandb running at the same time is not a good idea...). So, lets hope something here makes sense to somebody, and I have not made any false conclusions. False conclusion #1: now, it seems to crash regardless of if mandb is running or not. ARGGHH!! However, I have left in that in the message, in case it gives anybody else some ideas. -- Brian May <[EMAIL PROTECTED]>
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
> >The /etc/Muttrc in the mutt package makes a fruit salad of mutt. > Most people like it. BTW, the default key bindings in mutt are horribly broken. No key does what someone would expect.
blue on black is unreadable (was Re: Bug#60753: mutt: /etc/Muttrc should not use colors)
On Sun, Mar 19, 2000 at 10:20:30PM +0100, Marco d'Itri wrote: > On Mar 19, [EMAIL PROTECTED] wrote: > > >The /etc/Muttrc in the mutt package makes a fruit salad of mutt. > Most people like it. > > >When using mutt in an xterm, the color bindings in /etc/Muttrc make it > >very hard to read mail: 8 different colors on one screen, colored text > >on white background in the message but colored text on black background > >in the headers, it's just horrible. > > You are doing something wrong, that does not happens with the default > configuration. I think you have some color lines in your ~/.muttrc. I > had to experiment a long time to have settings which works fine both > in xterms and console, and I'm not going to change the default Muttrc > without a very good reason. most of your colour choices are fine, except for the following: color headerbrightblue default ^Subject: color body brightblue default (http|ftp)://[\-\.\,/%~_:?\#a-zA-Z0-9]+ on xterms/rxvts/powershell/whatever with a black background, it results in dark blue on black. this fg/bg combination has extremely poor contrast and is very difficult to read. i.e. the Subject line and URLs are almost unreadable. please consider this a wishlist request to change them to cyan or yellow instead of blue. in my ~/.muttrc, i've changed this to: color header brightyellow black ^Subject: color body cyan black (http|ftp)://[\-\.\,/%~_:?\#a-zA-Z0-9]+ btw, black backgrounds are better for your eyes - less glare, easier to get good contrast between foreground and background, and less eyestrain. lynx has the same problem. hyper links are blue on black, which makes it very difficult to see where you are going. fixed with: COLOR:1:cyan:black COLOR:5:brightcyan:black vim too. fixed with the folling in ~/.vimrc: set background=dark hi Commentterm=bold ctermfg=Cyan guifg=Cyan hi PreProcterm=underline ctermfg=Cyan guifg=#ff80ff craig -- craig sanders
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
On Sun, Mar 19, 2000 at 07:53:35PM -0300, Nicolás Lichtmaier wrote: > > >The /etc/Muttrc in the mutt package makes a fruit salad of mutt. > > Most people like it. > > BTW, the default key bindings in mutt are horribly broken. No key does > what someone would expect. that depends on what you're used to. if you've been using elm for years then mutt's key binding are perfectly 'natural' i used pine for years before switching to mutt. took me several days to re-train my fingers for the right keys, but the effort was worth it. i tried using the pine emulation bindings but they were more trouble for me than just learning the mutt keys. i've been using mutt for long enough now that pine's key bindings seem clumsy and awkward. craig -- craig sanders
