Bug#4582: mh `inc' can't lock mailbox
> According to /etc/mh/mtstailor, "lockstyle: 1" apparently means to do the > correct form of Debian mailbox locking, however `inc' isn't setgid mail so it > can't create the lock file. Just sticking in my two cents. I'm curious as to what changed on Debian to make this a requirement for mail programs. Pine, mail, tkmail, and of course inc are not sgid mail. Elm is the only one i've got on my system which is sgid mail. In any case the mail spool on my Linux box, now that I look at it, is odd: drwxrwxr-t 3 root root 1024 Aug 25 10:18 /var/mail Shouldn't it be group mail, or else set w permission of the user? Those are the two methods I'm familiar with (preferring the former). Jim -- Jim Robinson <[EMAIL PROTECTED]> - http://www.simons-rock.edu/~jimr/ Simon's Rock College.
Re: ae as default editor?
> However, I remember a discussion that, I believe, lead to this decision; > I can't remember all the discussions that have gone on here, there so very very many. ;-) > IIRC, it was the same idea that made ae (wrongly) essential - "all other > editors can be removed, so ae is a better fallback than vi". Well, I imagine if one takes that idea further, one would say that ae is the editor on the base disk because it is easier to use. Because it is on the base disk it has "recommended" status. And so on. I think the real reason goes back to the fact that experienced users can set their EDITOR variable, or handle ae. New users won't be able to handle something like vi, so we shouldn't dump them in it unless they call vi themselves. Jim -- Jim Robinson <[EMAIL PROTECTED]> - http://www.simons-rock.edu/~jimr/ Simon's Rock College.
Re: ae as default editor?
> Why is ae the default editor for vipw/vigr even on a completely > installed system? > > Doesn't VI-gr/pw suggest that a VI clone is executed? I can > understand to use ae as a fallback editor, but not as the main one Probably it is setup for the same reason ae is the default editor on the base disk. A new user, somebody who has only known DOS, WindowsX, or MacOS will probably be completely unable to deal with vi, but will probably be able to handle ae. Because these new users might be told to use vipw or vigr to edit the passwd or group file, it is better to stick them into a "friendly" editor. More experienced users will be able to set their EDITOR variable to call the correct editor (A more experienced user will also be able to get the job done in ae if need be). Jim -- Jim Robinson <[EMAIL PROTECTED]> - http://www.simons-rock.edu/~jimr/ Simon's Rock College.
Bug#4426: gcc bug #2
> It's *gnat* , not *gnats*. GNAT is the GNU Ada Translator; GNATS is > the Problem Report Management System :-) Right, sorry -- I was coming down off of being wired on expresso and not thinking/reading/associating very clearly. > override altogether (perhaps supplying an ada-gcc executable, which > would fail to compile C code if the gcc installation didn't > match... making it *much* clearer where the blame belongs.) Probably... Part of the problem is that dpkg doesn't summerize warnings about overrides -- if I run dselect and it chugs away, I'm likely to miss something important like this because it a) scrolls by too quickly or b) I'm off getting a glass of water. > Go ahead and reassign this bug to gnat. If you actually *use* gnat, > let me know, and in the meantime downgrading gcc will get it working > again. No, I don't use it -- and I don't think anyone using my system does either. But thanks for the info. Jim
Bug#4426: gcc bug #2
> Are you sure you don't have another gcc or cc1 in your path? The gcc > provided in the gcc package knows its own path. Ah hah! gnats or dpkg seem to be the culprite: [lestat:~/.www/unabomber/unabomber_writings]$ locate gcc|grep "gcc$"|xargs file|grep -i exec /usr/bin/gcc: ELF 32-bit LSB executable, Intel 80386, version 1 /usr/bin/gcc.orig-gcc: ELF 32-bit LSB executable, Intel 80386, version 1, stripped dpkg --search gcc.orig-gcc diversion by gnat from: /usr/bin/gcc diversion by gnat to: /usr/bin/gcc.orig-gcc [lestat:/home/jimr]# vi hello.c [lestat:/home/jimr]# gcc hello.c gcc: installation problem, cannot exec `cc1': No such file or directory [lestat:/home/jimr]# gcc.orig-gcc hello.c [lestat:/home/jimr]# So is gnats is scr?wing over gcc? > Some of us aren't on the debian-devel list and it's not by choice. :-( I think newsgroups are the way to go... :)
Bug#4426: gcc bug #2
Package: gcc Maintainer: David Engel <[EMAIL PROTECTED]> Version: 2.7.2.1-1 I don't know whether or not this is a gcc bug, but after I installed the latest rex stuff, gcc stopped being able to find cc1. After I added /usr/lib/gcc-lib/i486-linux/2.7.2.1/ to my path it worked, but I never needed to do that before (and gcc should know the path, shouldn't it?)... Sorry about the lack of information, but I posted a question to debian-devel and never got a response (too much traffic I guess...). Jim
Bug#4392: xfishtank coredumps at 16bpps
> Its not compiled for 16bpp. Could such programs then have a note telling us about that in the description? It looks bad when one downloads software and gets a core dump trying to run it. I think many people are running 16bpp, and many more will be running it as 2meg become the default -- is this a major problem with most fancy X programs (games and stuff)? Do they need to be compiled for different depths? Jim
Bug#4399: kpathsea
Maintainer: Nils Rennebarth <[EMAIL PROTECTED]> Version: 2.6-2 Provides: kpathsea Whenever I run dvips or xdvi I get a long list of "Errors" which show MakeTeXPK trying to create fonts that already exist. I'm really not sure if this is kpathsea's fault, but it is the one running MakeTeXPK. I guess it has some way of looking to see if the fonts exist or not, and this is not being done? [lestat:~/class/thesis]$ dvips thesis.dvi -o This is dvipsk 5.58f Copyright 1986, 1994 Radical Eye Software ' TeX output 1996.09.04:0930' -> thesis.ps kpathsea: Running MakeTeXPK cmbx12 1037 600 magstep\(3.0\) ljfour Running MakeTeXPK cmbx12 1037 600 magstep(3.0) ljfour /var/spool/texmf/fonts/pk/ljfour/cmbx12.1037pk already exists! kpathsea: Running MakeTeXPK cmbx12 1244 600 magstep\(4.0\) ljfour Running MakeTeXPK cmbx12 1244 600 magstep(4.0) ljfour /var/spool/texmf/fonts/pk/ljfour/cmbx12.1244pk already exists! ... kpathsea: Running MakeTeXPK cmbx10 600 600 1+0/600 ljfour Running MakeTeXPK cmbx10 600 600 1+0/600 ljfour /var/spool/texmf/fonts/pk/ljfour/cmbx10.600pk already exists! . [1] [2] [3] [4] [5] [6] [7] [8] [9]
Bug#4398: dpkg broken???
Package: dpkg Maintainer: Ian Jackson <[EMAIL PROTECTED]> Version: 1.3.14 I think dpkg may be broken -- when installing dvipsk it seems to either ignore or eat some files in the deb file. I manually unpacked the dvipsk.deb file with dpkg-deb --extract, and the config.ps file was there. Yet when I install it with dpkg -i, it either isn't unextracted or it gets removed. The dvipsk postinst just calls install-info. [lestat:/usr/lib/texmf/dvips]# dpkg -i ~debian/tex/dvipsk_5.58f-5.deb (Reading database ... 32822 files and directories currently installed.) Preparing to replace dvipsk 5.58f-5 (using .../debian/tex/dvipsk_5.58f-5.deb) ... Unpacking replacement dvipsk ... Setting up dvipsk (5.58f-5) ... [lestat:/usr/lib/texmf/dvips]# dpkg --search config.ps dvipsk: /usr/lib/texmf/dvips/config.ps [lestat:/usr/lib/texmf/dvips]# ls -l config.ps ls: config.ps: No such file or directory
Bug#4397: amstex
Package: amstex Maintainer: Nils Rennebarth <[EMAIL PROTECTED]> Version: 2.1-1 one of amstex's file seems to conflict with amsfonts, and it can't seem to find a tfm file it needs. This is the same error that was triggering massive multi-megabyte log files before, and I am thinking that error might related to xypic overwriting mflib's install-fmt-base, because at least with mflib's it does not go into an endless loop. [lestat:/usr/local/pub/debian/tex]# dpkg -i amstex_2.1-1.deb Selecting previously deselected package amstex. (Reading database ... 32759 files and directories currently installed.) Unpacking amstex (from amstex_2.1-1.deb) ... dpkg - warning, overriding problem because --force enabled: trying to overwrite `/usr/lib/texmf/tex/amstex/base/amssym.tex', which is also in package amsfonts Setting up amstex (2.1-1) ... kpathsea: Running MakeTeXTFM manfnt.tfm Running MakeTeXPK manfnt.tfm mf \mode:=nullmode; mag:=1; scrollmode; input manfnt \ ...=nullmode; mag:=1; scrollmode; input manfnt Please type another input file name: ! Emergency stop. <*> ...=nullmode; mag:=1; scrollmode; input manfnt Transcript written on mfput.log. Metafont failed for some reason on manfnt.tfm kpathsea: Appending font creation commands to missfont.log.
Bug#4396: xypic
Package: xypic Maintainer: Erick Branderhorst <[EMAIL PROTECTED]> Version: 3.2-4 xypic depends on mflib, yet it seems to overwrite mflib's 1.0.8's /usr/sbin/install-fmt-base with a different file. [lestat:/usr/local/pub/debian/tex]# dpkg -i xypic_3.2-4.deb (Reading database ... 32572 files and directories currently installed.) Preparing to replace xypic 3.2-4 (using xypic_3.2-4.deb) ... Unpacking replacement xypic ... dpkg - warning, overriding problem because --force enabled: trying to overwrite `/usr/sbin/install-fmt-base', which is also in package mflib Setting up xypic (3.2-4) ... [lestat:/usr/local/pub/debian/tex]# md5sum /usr/sbin/install-fmt-base 50b4a7afc2e563bf1005ba61ef1665d0 /usr/sbin/install-fmt-base [lestat:/usr/local/pub/debian/tex]# dpkg -i mflib_1.0-8.deb (Reading database ... 32572 files and directories currently installed.) Preparing to replace mflib 1.0-8 (using mflib_1.0-8.deb) ... Unpacking replacement mflib ... Replacing files in old package xypic ... Setting up mflib (1.0-8) ... [lestat:/usr/local/pub/debian/tex]# md5sum /usr/sbin/install-fmt-base 82b6c0cb83f75d91ca3533e0cf2085fb /usr/sbin/install-fmt-base
Bug#4358: smartlist
> But you need a list to test it. Right, but we might want to create "smartlist_tester" to test it. > Ok. I can ask for it. Thank you! > newaliases could only run when the automatic announce list is generated. Well, my point was that newaliases isn't _on_ my system, and if it fails the postinst exists with an error -- meaning dpkg thinks it is failed. > The hostname stuff works fine on debian 1.1.X. Seems that rex contains > an incompatible version. Will fix it on next release. Yeah, hostname 1.9 accepted the single dash, even though it doesn't claim to in its help -- 2.0 works the standard GNU way of wanting double dashs for any long option name. > That is what the standard script spits out. Could have a note appear > though to not take it for earnest. Or you could filter it out by redirecting stdout and stderr through sed or something. > There is another issue with Smartlist which is the automatic generation of > the list user. I do that with a sed script on /etc/passwd which is not You need to ask the base disk maintainer (Bruce?) to add the user to the passwd entry. > And could some kind soul finally get me on the debian-developers mailing > list? I have subscribed a couple of times with no result by writing > email to the request address. Ugh, I've been reading about problems with this (getting ahold of the list mainter). It looks like they might be switching servers so somebody with more time can handle all the devel requests... Jim
gcc just sorta broke...
I just had dselect run through the latest and greatest in rex, and then found out that something in there broke gcc's ability to find cc1. I just added the directory to my path, and got gcc working again, but I believe one does not normally need to do this. Gcc should know where the correct preprocessor and other things are, right? Jim
Bug#4358: smartlist
Package: smartlist Version: 3.10-1 Hello, I noticed a few problems with the smartlist when I installed it (to check out whether or not it is a candidate to replace majordumbo) My first thought was that the postinst should probably ask whether or not it should set up an announce mailing list -- we might already have such an aliases, or be using majordomo, or just want to check smartlist out without creating a list yet. The postinst is broken, it should use "hostname --fqdn" not "hostname -fqdn" (the extra dash does it...). The postinst should also check to see whether or not newaliases exists before trying to run it, since some of us haven't get our MTA set up to use it. I thought it might get rid of "add following to /etc/aliases from the "create announce" it does, because it adds the aliases itself. Jim
Re: HELP! (pppd and slirp)
On Thu, 22 Aug 1996 02:01:47 -0400 I wrote: < re pppd and slirp I must have been really tired when I sent this -- I don't know why I wrote debian-devel in the To: list. Well, nobody responded but I figured it out anyway. It seems as though problem was likely to come partly from the kernel not having a proper System.map (and killing syslog), and partly from expecting the kernel daemon to load slhc properly. Once set up modules to load slhc and pppd in the order specified in the README, and fixed the map, I was able to get debugging info and have ppp work. Thanks, Jim
HELP! (pppd and slirp)
If anyone out there has pppd working with slirp, I would surely appreciate getting a copy of their chat and options file (remember to edit our the password!). I've been trying on and off for weeks now, spending 15 minutes trying to figure out why pppd dials, seems to connect, and then hangs up (no debugging info shows up in messages, daemon, or debug...). I've decided to give up and ask for help. Anyone? Jim
Re: Perl vs Python vs ....
Much of this discussion (talking about MS-DOS, assembler code, etc.) has no real place for debian developers. I've asked Bruce to say something, and he told me to ask you all to please move this discussion off the list. Please take it to private e-mail or something for now. Jim
Bug#4012: xbase: `window-managers' was un-correctly generated
> I believe that the 3 first extra explanatory lines in file `xbase.postinst' > of this package should be removed as they trigger unexpected result in some > cases (can go into an infinite loop as Xsession will call itself if you Perhaps the Xsession should be for i in `grep -v "^#" '/etc/X11/window-managers'` do or for i in `sed -e /^#/d '/etc/X11/window-managers'` do > == /etc/X11/Xsession = [...] > for i in cat `/etc/X11/window-managers` do [...] > == > == xbase.postinst > cat >/etc/X11/window-managers < # This file contains a list of available window managers. The default > # Xsession file will start the first window manager that it can > ^^ > # in this list. > /usr/X11R6/bin/fvwm > /usr/X11R6/bin/twm > EOF > ==
Re: perlconfig creates unnecessary/unusable files.
> it also runs h2ph in the foreground, when there's no good reason why it > shouldn't run in the background and let dselect get on with the rest of > the install process. Some people don't like this (IMO, very sensible) approach. So there needs to be options given. What I'm going to do is write a tiny script where the package maintainer and give it a command line, and it will give the user the choice of running it in the foreground, or running it in the background and putting output in a file. [Side Note: I wonder if I should use Ada, Agol, Assembler, C, CSH,] [Cobol, Eifel, Fortran, KSH, Lisp, Perl, Pascal, Python, SH, or] [Smalltalk to do it? :-) :-O :-Q :-)] Jim
netpbmdevel-1994.03.01p1-1
-BEGIN PGP SIGNED MESSAGE- Date: 30 Jun 96 22:33 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: Jim Robinson <[EMAIL PROTECTED]> Source: netpbmdevel Version: 1994.03.01p1-1 Binary: netpbmdevel Architecture: i386 Description: netpbmdevel: Netpbm development libraries and header files. Changes: First upload. This is a split-off from netpbm proper. -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBMdcA2Cu/XyBsR8PBAQGSGwP+OATEaPzei84nNGdPlmBmq/L9uqtL6D3Z c7lwYUIrtL1IhnBSvsk379Eo9dr9b/P+QsXmIrWCLSeG+8UDDb7Umhg5s2od7w7T 5P/66GMxq221DA7w/qfKEVt1w/7dsMfRdXzj7HxxkzIj5R7dD33csk6e5+5HFt/7 DXBc6QEjzLw= =qDpg -END PGP SIGNATURE-
netpbm-1994.03.01p1-1
-BEGIN PGP SIGNED MESSAGE- Date: 30 Jun 96 22:34 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: Jim Robinson <[EMAIL PROTECTED]> Source: netpbm Version: 1994.03.01p1-1 Binary: netpbm Architecture: i386 source Description: netpbm: netpbm -- graphics conversion tools. Changes: First upload. Files: 3497a7c344ccf7181123386d4a486845 1285898 non-free - netpbm-1994.03.01p1-1.tar.gz 68b9960a0665f6badfe19e8369f6ec1f 42595 non-free - netpbm-1994.03.01p1-1.diff.gz c5cf76f98c59754e112c096ec9c99539 730148 non-free extra netpbm-1994.03.01p1-1.i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBMdcBKSu/XyBsR8PBAQGwiQP/Z6MrHDjVonBifop9G+Q+NvXV6BNK+ue0 np7f7rbcqhtOKaOV9LLpJlpBgM+QGilB6XlCwK33oCpZqJqYLbiPiRH2cYnz0AhJ bn1bH9t/JTND8VUxx4RQQvIuBjL7caRQIVbb+iIxMbTQKHNKIVZXAwXoZyl/w6Lp 5egg8UfgQ3M= =8bWd -END PGP SIGNATURE-
zircon-1.17p1-1
-BEGIN PGP SIGNED MESSAGE- Date: 30 Jun 96 17:56 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: Jim Robinson <[EMAIL PROTECTED]> Source: zircon Version: 1.17p1-1 Binary: zircon Architecture: i386 source Description: zircon: An X11 interface to Internet Relay Chat. Changes: Upgraded to new version. Files: 4bdcd14f3a149a34986704b1ee1c31a4 199713 net - zircon-1.17p1-1.tar.gz 402bf20fe9f89c7b9835ea9996e43238 10226 net - zircon-1.17p1-1.diff.gz b9c30885fb5a62a2cfc87dfa04543d9e 198632 net extra zircon-1.17p1-1.i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBMdbADiu/XyBsR8PBAQG6NgQAjkz8oI+xFsTMeaTZsei9KkL4DTRoh3hL 3DD7a57heDAxDQVQwhXQEiVb4QLb0RaZKAKwY2pHgx/Nubm5BVEx4Wl9YqffmBxS YWuR2g175CHmL5nWy2Azu/htOU8lkrWPZtKfXPiIcR87nlbjlF2Z2HjLdiCXPnl0 FuEB/CFTfuE= =yAz9 -END PGP SIGNATURE-
auctex-9.3c-3
-BEGIN PGP SIGNED MESSAGE- Date: 23 Jun 96 22:50 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: Jim Robinson <[EMAIL PROTECTED]> Source: auctex Version: 9.3c-3 Binary: auctex Architecture: i386 source Description: auctex: An integrated environment for writing TeX/LaTeX documents. Changes: Removed absolute paths from calls to install-info in scripts. Files: d14abbe8bc8ccb755d9aa326685ab49d 268996 tex - auctex-9.3c-3.tar.gz b4f9a8b20390beca4e14e73f8f92790c 270675 tex - auctex-9.3c-3.diff.gz 27d758771342c5d36f9ea4e2916881f6 324310 tex extra auctex-9.3c-3.i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBMc3KbCu/XyBsR8PBAQEYrQP9HXa6pwC02y5zxMNl82dQvDLxwcDWZDpG 2Gztn6rAKMIRVz9K0KY/9N6KVfyegBqWg1iHBKzLOQdyD5Kbx7R7nxUNMcXtdYSC NNiWCK7bx6N3/EQGfYpvRBR4QhJ1tFfF7ArSHl3bT/TyYD51eStWW9mULksgqSye Xd7sbn5h8Ok= =iH8K -END PGP SIGNATURE-
Re: Bug#1979: auctex postinst is completely insane
> > Package: auctex > Version: 9.2y-7 > > The postinst backgrounds itself. How can you tell if it succeeds or > fails ? The postinst steps through the tex directories and generates .el code for auc-tex's use. This process can take a long time on slow machines. I decided to background it, and output all data to a /tmp file. It tells the user this information. The alternative is to sit around and wait 30 minutes while it builds all the files on slow machines (30 to 45 minutes on an old 486 w/ 8 megs RAM). Perhaps I should have postinst ask whether or not the .el file should be generated? And have a script to go through and make them? Should it never be backgrounded? Jim
Re: symlink in /usr/include (fwd)
> How about installing the kernel headers directly in /usr/include, > rather than linking them into /usr/src? I always assumed this was > standard kernel practice. Apparently, I was wrong. Are there any > opinions on the subject? I doubt it would affect a lot of people. But putting the includes in /usr/include will make it a bit of a pain in the ass for people who want to upgrade their kernel without using Deb packages. What is Stallman's objection to the link anyway? Jim
Bug#421: unreasonable restriction on term
> Return-Path: <[EMAIL PROTECTED]> > Tue, 19 Sep 1995 14:31:41 +0200 > Date: Tue, 19 Sep 1995 14:31:41 +0200 > From: [EMAIL PROTECTED] (Sven Rudolph) > Message-Id: <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Bug#421: unreasonable restriction on term > > You already changed the DEPENDS to RECOMMENDED, so the problem is > solved and you should close the bug. > > (It might make sense to invent a name for a dialer virtual package, > but > you have to ask debian-devel about it.) > > Please write me if you believe that I got somthing wrong. > > Sven > -- > Sven Rudolph ([EMAIL PROTECTED]); WWW : http://www.sax.de/~sr1/ >
Re: antisocial X11 apps: xtet42, chimera
> Dx -- dunno. Didn't take note when I had it open. I grepped > /var/log/messages for a bogomips figure, but that's apparently > no longer part of the startup. As I recall under earlier kernels, > it was low -- perhaps 6.something. Better than the 386 I used > to run, which was about 4.3. > > 16 MB RAM -- machine unbusy and not swapping. > Cirrus video card with 1Mb on it. It might be a video-driver problem. Awhile back when I had my 486 with an ATI 8514/A card, I sent mail to the list saying that Netscape would not work for me after some kernel upgrades, Netscape would freeze the system up. Nobody could duplicate the problem, but when I moved my hard drives over into my new system, everything worked fine. So I would suspect a hardware problem (either physical or software driver). Perhaps you could try borrowing a video card from somebody else and seeing if that changes anything? How well do compiles go, do you notice it being slower then it should? Jim
Bug#1801: tar manpage missing
> I am considering starting a project which would: > a) define a standard template for man pages in Linux. I know it would > appear that one already exists, but it turns out that what really, really > exists is a good overall description of what should be included in the > man pages (in /usr/doc/HOWTO/Mini/Manpages), but that's leaves room > for ambiguities, and I believe a template would be a very useful addition. You know, it would be _really_ cool if somebody wrote an emacs macro or perl script that let you just call up an editor for the various sections of a man page, and then have it automatically make the proper nroff manpage. > b) begin the slow, laborious process of writing new manpages where they > don't exist, then start re-formatting existing man pages to a standard > template. Wow. Lots of work, you should talk to the current manpage gurus who maintain man-pages (v1.8). Jim
Bug#1804: manpage of irc missing
> Package: irc > > The manpage of irc is missing. The program is IrcII, so: [lestat:~]$ apropos ircII ircII (1)- interface to the Internet Relay Chat system My personal opinion is that apropos should do fuzzy matchs to catch things like this. :) Jim
Re: Debian for Linux/{non-i386} / source packaging
> I'll go further and say that I think that any approach that does not > include as one of its goals the ability to work with totally virgin source > archives is a total waste of time because it doesn't buy us enough to > justify the work. Now hold on a second there! What about packages put together from multiple sources? Say MH with Linux patchs? I don't want to deal with writing something that will be able to intelligently do the patchs needed and then make the source. If you go too far down this road, you get back to the maintainer having to write the entire script himself -- which means they will be prone to bugs and unusual differences in form/style. Jim
Re: changes file format
> I completely fail to understand why anyone is promoting this format. > > It is ugly, and my format is machine readable too. But Ian, almost _any_ format can be made machine readable -- but Bill's format is _easily_ machine readable -- you could slap together a whole bunch of ways to read it. I'm very much against going all out for "beauty" when you can have a nice compromise between beauty and easy functionality. I just had to deal with such a problem with our people who make up the Faculty and Staff directory at my school. They _insist_ on making it in Word. So I get very nice looking ascii text: Jim RobinsonLibrary 371 Network Administrator Network, Room 6 The Cottage Simon's Rock College Great Barrington, MA 01230 528-8150 That is an absolute nightmare to pull apart -- the second "column" format is constantly changing, as is the little "extras" they add for people with more then one phone: "334 Tue, 320 Mon-Fri" in the phone section, and so on! Compare to: Jim Robinson (jimr): Network Administrator Networking Office. Phone: (413) 528-7371 Fax: (413) 528-7380 Internet mail: [EMAIL PROTECTED] Now, the information content is slightly different, but I find the latter just as "readable" if not as pretty. The latter format is also much easier to pull apart with code. > Are you saying it looks anywhere near as nice as mine ? (Ra ra ra > format wars.) This sounds really childish, I suppose, but there is an > important issue here: having our release announcements and changelog > files look good and be easily readable is important. > > Given that both formats are machine-readable and that they have almost > exactly the same content there seems little reason to choose the > uglier of the two. Hmm, in perl your format is easy to pull apart, in his, perl, awk, and cut could do it with no problem. I don't know -- I just squirm at having to deal with database like information without keys. I usually want to do things with database like information, and if I have to write a context-dependent parser, it gets irritating. > > I also happen to like seeing the MD5SUM and file size information. > > In my format you can pass the md5sum information to `md5sum -c'. To check it? That is nice. Perhaps you two can merge formats -- somehow get a "key" field in there? Let's stop bickering, and start trying to really help one another. This is getting as tiresome to watch as the Matt/Ian/Stephen/ wars. Jim
Re: changes file format
> Just out of curiosity, does the following represent a horribly > formatted and human-unreadable package announcement? Except for > the lack of a Priority field, it passes the dchanges(1) syntax check. Very nice! I think it looks quite good. I also happen to like seeing the MD5SUM and file size information. Jim
