Re: changes file format
On Tue, 24 Oct 1995, James A. Robinson wrote: 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'd intended to drop this topic, but I'll belabor one point here. If package announcements are uploaded to debian.org for machine parsing and debian-changes announcements are machine-generated from there, The mechanized debian-changes announcement generator has a lot of control over the aesthetics of the announcement format which is presented to humans for reading.
Re: bc-1.03-8 uploaded
On Sun, 22 Oct 1995, Ian Jackson wrote: Bill Mitchell writes (bc-1.03-8 uploaded): added /usr/doc/dc with dc.texinfo man Makefile [...] Why ? The texinfo file is a piece of source code and belongs in the source package. Actually, I thought back to an exchange you and I had perhaps a year or more ago regarding elv-vi.doc. You objected to the separate doc package and said the compressed sources for the docs should go in /usr/doc/elvis with a makefile. I put this recollection together with a picture of a user who might find printable documentation useful. /usr/doc seemed like the appropriate place for that (installed with dselect, like everything else). Since the distribution provides tools to get from a texinfo file to a printable doc, I thought the texinfo file was appropriate. I didn't even consider that the user might want to dig up a copy of the source package, grub thru it, figure out how to build the docs, and construct them manually. That seems to me like too much to ask. Looking in /usr/doc, I see that a number of other packages have docs and Makefiles, though I seem to be alone at the moment in providing a texinfo file for the Makefile to build from. The convention with all the other packages is to put the generated info file in /usr/doc/info. I happen to read better horizontally than I do vertically. I don't find info very useful, and find paperclipped manual pages more useful than hyperlinks. Many of the people I work with likewise find printed docs more useful than info. I don't think that's too uncommon. I think that if we want to distribute any other format we should put the formatted version in /usr/doc. Compressed .dvi files? Compressed .ps files? I guess I could see compressed .dvi files. (elvis1.8pl4 is an exception here, since its documentation comes as .ms files. I've provided compressed docs sources and a makefile for that in /usr/doc/elvis for some time now.) In any case, it seems very unwise to put effort into changing all your packages in line with some new policy without first discussing whether the policy is a good one ... Perhaps I did jump the gun here. It seemed reasonable at the time (and, actually, still does). I'll adopt whatever consistent policy may be established, but I think we should do more than say dig the raw material to build docs out of the source package if it's needed.
Bug#1761: error in elf-libgdbm postinst
Package: elf-libgdbm Version: 1.7.3-0 Installing produces the following error: Selecting previously deselected package elf-libgdbm. Unpacking elf-libgdbm (from elf-libgdbm-1.7.3-0.deb) ... Setting up elf-libgdbm ... /var/lib/dpkg/info/elf-libgdbm.postinst: /sbin/ldconfig: No such file or directory dpkg: error processing elf-libgdbm (--install): subprocess post-installation script returned error exit status 126 After upgrading to ld.so-1.7.10-1, the problem went away. --Mike
Bug#1739: syslog is uncommented in /etc/services by default
Hallo Ian Jackson! }Peter Tobias asks me in email: } Ian Jackson wrote: } Package: netbase } Version: 1.19-1 } } I've now tracked down what it is that keeps reenabling my syslog's } network listening: the netbase package's /etc/services file has syslog } uncommented. } } Commenting out the /etc/services entry is of course a very nasty way } of nixing syslog's usually-undesirable network listening feature, but } we should leave things that way until the syslog package is improved. } } Why do you think it's a bug in the netbase package? This feature (and } the syslog entry in /etc/services) is enabled on the systems that } support it (at least on those I have access to). And I see no problem } having it enabled by default. Anyway, it shouldn't be fixed by } commenting out the syslog service in /etc/services. It should be fixed } in the syslogd package. } }It's a security problem, because it allows any machine anywhere on the }Internet to make your maching completely unusable very easily. syslog }writes its logfiles to disk synchronously, and the logs can fill up }the disk too. Yes. We (the sysklogd developers) found this problem long time ago. Future releases will have a switch (-r) that has to be set if any message should be received from remote. Otherwise the syslogd won't open the socket for reading. This to look in the future... }Most people do not need or want the remote logging feature. That's correct. }It should therefore be disabled by default. dito }I agree that it shouldn't be fixed by commenting out the syslog entry }in /etc/services, but that seems to be the only avenue open at the }moment. Please keep the entry commented out until the syslog package }is fixed. I have one more comment to make. What do you think about an explanatery text when installing the sysklogd package. This could be done in my postinst script (if I'm not mistaken). Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / +49-441-777884 * LoginPasswd: nuucp * Index: ~/ls-lR.gz / / [EMAIL PROTECTED] / /verursacht durch kaputte Gatesoftware auf der CyberBox / 30.10.95: Oldenburger Linux-Stammtisch, ab 20h im DaCapo
Bug#1762: elf perl depends on non-existent library
Package: perl Version: 5.001-5.elf The new elf perl package depends on version 5 of the math library. However, as far as I can tell, version 5 has not been released yet (as a debian package). Preparing to replace perl (using perl-5.001-5.elf.deb) ... Unpacking replacement perl ... Setting up perl ... Creating Perl header files. This may take a while... perl: can't load library 'libm.so.5' perl: can't load library 'libm.so.5' perl: can't load library 'libm.so.5' fgrep: wait.ph: No such file or directory Found 0 occurances of '* ' where I expected 1. Please report this as a bug to Carl Streeter [EMAIL PROTECTED]. Done. You can re-run this script at any time as 'perlconfig'. You should do this any time you install new header files in /usr/include. --Mike
Bug#1762: elf perl depends on non-existent library
Package: perl Version: 5.001-5.elf The new elf perl package depends on version 5 of the math library. However, as far as I can tell, version 5 has not been released yet (as a debian package). There is, see the following transcript from ftp.debian.org: -- bugs jdassen 3:42 /debian.org/ftp/debian/project/experimental/elf# dpkg-deb --contents elf-libc-5.0.9-2.deb | grep libm -rwxr-xr-x root/root 35942 May 18 23:47 1995 usr/i486-linuxelf/lib/libm.so.5.0.0 -rw-r--r-- root/root 82236 May 18 23:47 1995 usr/i486-linuxelf/lib/libm.a -rw-r--r-- root/root 2668 May 18 23:48 1995 usr/i486-linuxelf/lib/libmcheck.a bugs jdassen 3:42 /debian.org/ftp/debian/project/experimental/elf# dpkg-deb --contents elf-libc-5.2.7-1.deb | grep libm -rwxr-xr-x root/root 35553 Aug 14 21:22 1995 usr/i486-linuxelf/lib/libm.so.5.0.3 -rw-r--r-- root/root 82200 Aug 14 21:22 1995 usr/i486-linuxelf/lib/libm.a -rw-r--r-- root/root 2668 Aug 14 21:22 1995 usr/i486-linuxelf/lib/libmcheck.a -- Which elf-libc are you using? Ray -- PATRIOTISM A great British writer once said that if he had to choose between betraying his country and betraying a friend he hoped he would have the decency to betray his country. - The Hipcrime Vocab by Chad C. Mulligan
Bug#1763: sysklogd init script has no links to rcx.d
Package: sysklogd Version: 1.2-13 There were no links to /etc/init.d/sysklogd in /etc/rc2.d so klogd and syslogd didn't get started. The culprit is these lines in the postinst script. update-rc.d sysklogd defaults 10 90 /dev/null # Purge the files of the old syslog package, it's now called sysklog. rm -f /etc/cron.weekly/syslogd /etc/init.d/syslogd \ /etc/rc[0-6].d/[SK]20syslogd \ /etc/rc[0-6].d/[SK]20sysklogd Your making the links, then deleting them afterwards. Andrew -- Dehydration - 34%, Recollection of previous evening - 2%, embarrassment factor - 91%. Advise repair schedule:- off line for 36 hours, re-boot startup disk, and replace head - wow, what a night! -- Kryten in Red Dwarf `The Last Day' Andrew Howell [EMAIL PROTECTED] Perth, Western Australia [EMAIL PROTECTED]
Bug#1764: /bin/kill segfaults
Package: bsdutils
Version: 1.3-1
It is trivial to make /bin/kill segfault:
$ /bin/kill -l
INT QUIT ILL TRAP ABRT UNUSED FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT CHLD
Segmentation fault (core dumped)
The appended patch fixes the bug. I suspect the person who wrote the code
has had some bad memories about Pascal :)
PS NSIG is the largest valid signal number + 1.
--
A. B = True B. A = False
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
PGP Key: [EMAIL PROTECTED] or any other key sites
--
--- kill.c.orig Wed Mar 22 05:57:31 1995
+++ kill.c Wed Oct 25 15:33:21 1995
@@ -57,8 +57,8 @@
QUIT, /* 3 */
ILL, /* 4 */
TRAP, /* 5 */
- ABRT, /* 6 */
- UNUSED,/* 7 */
+ IOT, /* 6 */
+ BUS, /* 7 */
FPE, /* 8 */
KILL, /* 9 */
USR1, /* 10 */
@@ -74,6 +74,15 @@
TSTP, /* 20 */
TTIN, /* 21 */
TTOU, /* 22 */
+ URG, /* 23 */
+ XCPU, /* 24 */
+ XFSZ, /* 25 */
+ VTALRM,/* 26 */
+ PROF, /* 27 */
+ WINCH, /* 28 */
+ IO,/* 29 */
+ PWR, /* 30 */
+ UNUSED,/* 31 */
NULL
};
#endif /* __linux__ */
@@ -105,7 +114,7 @@
if (isalpha(**argv)) {
if (!strncasecmp(*argv, sig, 3))
*argv += 3;
- for (numsig = NSIG, p = sys_signame + 1; --numsig; ++p)
+ for (numsig = NSIG, p = sys_signame; --numsig; ++p)
if (!strcasecmp(*p, *argv)) {
numsig = p - sys_signame;
break;
@@ -116,7 +125,7 @@
numsig = strtol(*argv, ep, 10);
if (!*argv || *ep)
errx(1, illegal signal number: %s, *argv);
- if (numsig = 0 || numsig NSIG)
+ if (numsig = 0 || numsig = NSIG)
nosig(*argv);
} else
nosig(*argv);
@@ -156,7 +165,7 @@
const char *const *p;
int cnt;
- for (cnt = NSIG, p = sys_signame + 1; --cnt; ++p) {
+ for (cnt = NSIG, p = sys_signame; --cnt; ++p) {
(void)fprintf(fp, %s , *p);
if (cnt == NSIG / 2)
(void)fprintf(fp, \n);
Bug#1763: sysklogd init script has no links to rcx.d
Andrew Howell writes (Bug#1763: sysklogd init script has no links to rcx.d): Package: sysklogd Version: 1.2-13 There were no links to /etc/init.d/sysklogd in /etc/rc2.d so klogd and syslogd didn't get started. The culprit is these lines in the postinst script. update-rc.d sysklogd defaults 10 90 /dev/null # Purge the files of the old syslog package, it's now called sysklog. rm -f /etc/cron.weekly/syslogd /etc/init.d/syslogd \ /etc/rc[0-6].d/[SK]20syslogd \ /etc/rc[0-6].d/[SK]20sysklogd Your making the links, then deleting them afterwards. Since the package should not have been renamed (see my recent message on debian-devel) this is all moot, but what should really have been done was just to add the extra `k' to the existing links. Removing the user's configuration and replacing it with the default one isn't good. Ian.
Re: sysklogd-1.2-13 released
Date: Sun, 22 Oct 95 16:59 GMT From: Ian Jackson [EMAIL PROTECTED] Martin Schulze writes (sysklogd-1.2-13 released): I'm just trying to upload this package. The changes are only minor ones. Here are the relevant ChangeLog entries ... * changed the name in control file (Bug#1695) Aaargh, no ! Please, change it back. [...] Ian M.: please do not move this release into the public area. Er, I did that a few days ago...
Bug#1765: /etc/init.d/xdm (and xfs) still sources /etc/init.d/functions
Package: xbase Version: 3.1.2-4 The /etc/init.d/xdm (and xfs) scripts still source /etc/init.d/functions - known problem, just yet another package to fix... Marek
Re: changes file format
Bruce Perens writes (Re: changes file format ): [EMAIL PROTECTED] said: Are you saying it looks anywhere near as nice as mine ? Well, I think it looks awful, but I will accept your format simply to end this argument if you or someone else will write and maintain the parser for it and an automated tool to generate it. Sorry to labour the point, but when you say it looks awful do you mean from a human's point of view or from the point of view of making it easy to write a parser ? One of the main advantages of my format is that it can be used in changelogs too. How about the following proposal: Release announcements are prepared in whatever way the package maintainer likes, and submitted in a format that looks like yours. The announcements are reformatted into a format that looks like mine, before being posted (to the instant-updates list, see below). When the package is moved into view the `human-readable' announcement is added to the global system changelog file, and posted to debian-changes (or whatever the updates-when-available list is). I can write a program to convert between the two formats, so that if you edit your changelog in my format you can generate the release announcement in dchanges format and never have to read it. This will localise the problems with badly-formatted human-readable changelogs to the package maintainer. The only thing I think I need to do this is a way to represent a blank line in the dchanges format's Changes field. I don't see how you could seriously propose a context-dependent parse, but I'm sick of the argument. I'll write a grammar for it if you *really* want me to, but it seems like a waste of effort. Actually, here you are: release-announcement: change-log md5sums listing change-log:header change-lines footer change-lines: change-line change-lines | change-line: rest-of-line end-of-line | end-of-line end-of-line: end-of-line | \t end-of-line | \n rest-of-line: any character except \n * header:package-name ( package-version ) status-flags priority-flags end-of-line package-name: letter or digit or -_+.@:=% + package-version: any character except \n, (, ) + word: letter letter or digit or - * status-flags:status-flag status-flags | status-flag: BETA | ALPHA | stable | experimental | word priority-flags:; priority-setting other-priorities priority-setting: priority= priority-value priority-value:LOW | MEDIUM | HIGH | URGENT | word other-priorities: ( any character except ),\n + ) | footer: -- maintainer-info maintainer-inforfc822-date end-of-line maintainer-info: any character except \n or or + rfc822-date: the date specification from RFC822 md5sums: ( md5sumfilename ) + listing: the output of `ls -l' See my comments about the ls output in another message. Ian.
Re: changes file format
Bill Mitchell writes (Re: changes file format ): [...] I also reiterate my suggestion that we stop the practice of maintainers announcing directly (and prematurely) to debian-changes, and have the maintainer announcements uploaded to debian.org along with the other package files, machine-parsed there, and machine-produced announcements in whatever announcement format is deemed appropriate incorporating information from the machine-parsed maintainer uploads made from debian.org once the packages being announced are actually available as part of the distribution. No, this has even worse security properties than the scheme we have at the moment. It's important that the distribution channels for the MD5 checksum information and the files themselves remain separate. (For this reason I think that putting the MD5 checksums in the Incoming directory itself is bad - there should be a separate administrative directory.) It would be best if every announcement were reviewed by a human before being passed to the automatic distribution and changelog maintenance software. Ian.
Re: changes file format
James A. Robinson writes (Re: changes file format ): 847dfb732aa3e994f1917d27ffc20eb3 adduser-1.94-2.deb 70fa124c71e5b709019f6729eb8cfe11 adduser-1.94-2.tar.gz -rw-r--r-- 1 root root13122 Oct 23 18:43 adduser-1.94-2.deb -rw-rw-r-- 1 root ian 24448 Oct 23 18:43 adduser-1.94-2.tar.gz ^ File permissions, link count, ownership an modification times on the maintainer's system are not of general interest, why include them in an announcement? The rest easily fits onto a single line and put the fixed length parts in front. I agree that this is a kludge, and I would write a separate script to produce a less overblown output form. However # md5sum size name 70fa124c71e5b709019f6729eb8cfe11 24448 adduser-1.94-2.tar.gz 847dfb732aa3e994f1917d27ffc20eb3 13122 adduser-1.94-2.deb With fixed length fields the dchanges format will yield a nice readable table and a trivial pipe (left as an exercise to the reader) lets you check the md5sum. this is not good enough. Remember, our release announcements are intended for general consumption and use perhaps even on MSDOS systems, where `a trivial pipe' is a major undertaking. We need to be able to feed the announcement to `md5sum -c', which expects checksum space space filename. Ian.
Re: inverse of `adduser'?
In article [EMAIL PROTECTED] you wrote: : * delete mail spool file (what if it's nonempty?) Tell the person running the script it's non-empty, and ask if they want it deleted, anyway. : * delete home directory. What do we do about saving : files? Sometimes we want it nuked, sometimes we want it saved. How about a do you want me to remove the users home directory and all its contents? query? : * maybe clean up files owned by the user or their group : under /tmp and /var/tmp? I wouldn't bother. Trimming the contents of tmp directories is a religious issue. : * what about files owned by this user in other : directories? (Shared projects, etc.) We tend to leave them as-is, which I'm not sure is smart. On the other hand, a find from / is expensive on a system with lots of disk... : * what if the user has processes running? Or a print : job queued? Or mail queued? Life is too short to worry about this. : * there should be a man page ;-) Of course! : Maybe it should be possible to delete everything from the home : directory except a .forward file. Actually, in my shop we don't allow .forward files to remain for folks who have left. We have a whacked up copy of 'vacation' that is designed to return the entire message to the sender with a prepended explaination that the person has left, and where to find them now. By forcing the originator of the mail to update their distribution lists and handle the message themselves, we've discovered that we can get the mail traffic for someone to tail off and get switched to the new address very quickly. Subtle, but behavioural engineering really works... :-) Bdale ps: I should probably explain that, by day, I'm the Technical Computing Manager for HP Colorado Springs, and my staff and I babysit several hundred HP-UX and Sun systems, plus a like number of networked PC's. I'll probably slip into the use of 'we' from time to time, this is the context in which 'we' applies, most of the time... :-)
Re: inverse of `adduser'?
* what if the user has processes running? Or a print job queued? Or mail queued? Life is too short to worry about this. Actually I should have written `kill any processes the user owns' without opening that point to discussion since leaving them running has obvious security problems. Maybe it should be possible to delete everything from the home directory except a .forward file. Actually, in my shop we don't allow .forward files to remain for [...] Fair enough, though I'm inclined to think that this should be a local decision. ttfn/rjk
Re: inverse of `adduser'?
: * what about files owned by this user in other : directories? (Shared projects, etc.) We tend to leave them as-is, which I'm not sure is smart. On the other hand, a find from / is expensive on a system with lots of disk... Finding the files and expunging them should probably be an option for deluser (which, IMO, should be adduser -d or adduser --delete). Let the sysadmin using it decide whether that's too expensive for him, in his situation. Don't make the decision for him and expect him to like it.
Bug#1762: elf perl depends on non-existent library
Ray, On Wed, 25 Oct 1995 08:44:20 +0100 (MET), [EMAIL PROTECTED] (J.H.M.Dassen) said: bugs jdassen 3:42 /debian.org/ftp/debian/project/experimental/elf# dpkg-deb --contents elf-libc-5.2.7-1.deb | grep libm -rwxr-xr-x root/root 35553 Aug 14 21:22 1995 usr/i486-linuxelf/lib/libm.so.5.0.3 -rw-r--r-- root/root 82200 Aug 14 21:22 1995 usr/i486-linuxelf/lib/libm.a -rw-r--r-- root/root 2668 Aug 14 21:22 1995 usr/i486-linuxelf/lib/libmcheck.a Which elf-libc are you using? I'm using elf-libc-5.2.7-1. Should the linker accept libm.so.5.0.3 as a match when it is searching for libm.so.5? I'm at work now. I'll double check this tonight. Perhaps there was a problem when I installed elf-libc. --Mike
Re: inverse of `adduser'?
Bill Mitchell writes: * what about files owned by this user in other directories? (Shared projects, etc.) We tend to leave them as-is, which I'm not sure is smart. On the other hand, a find from / is expensive on a system with lots of disk... Finding the files and expunging them Um, I was thinking more of arranging for them to be changed to another uid, or at least telling the sysadmin they exist - leaving them as they are risks trouble when some new user is created. If I leave the company I work for I'm sure they won't want to delete all the files I worked on in shared directories. should probably be an option for deluser (which, IMO, should be adduser -d or adduser --delete). *shrug* Let the sysadmin using it decide whether that's too expensive for him, in his situation. Don't make the decision for him and expect him to like it. Agreed. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#1763: sysklogd init script has no links to rcx.d
Ian Jackson writes: Since the package should not have been renamed (see my recent message on debian-devel) this is all moot, but what should really have been done was just to add the extra `k' to the existing links. Considering it's now in binary/base and probably on the new disk set Bruce is making I wouldn't call it moot. Removing the user's configuration and replacing it with the default one isn't good. I agree. Andrew -- Dehydration - 34%, Recollection of previous evening - 2%, embarrassment factor - 91%. Advise repair schedule:- off line for 36 hours, re-boot startup disk, and replace head - wow, what a night! -- Kryten in Red Dwarf `The Last Day' Andrew Howell [EMAIL PROTECTED] Perth, Western Australia [EMAIL PROTECTED]
Re: inverse of `adduser'?
Richard Kettlewell [EMAIL PROTECTED] said: Um, I was thinking more of arranging for them to be changed to another uid, or at least telling the sysadmin they exist - leaving them as they are risks trouble when some new user is created. If I leave the company I work for I'm sure they won't want to delete all the files I worked on in shared directories. Most places I've worked didn't delete departed users. They left the users defined, and put a * in the passwd field of /etc/passwd. I guess it's designer's choice here regarding deleted users' files. However, it seems that there are too many possibilites to hope to cover them all (chown to another user, delete, back up offline and then delete, tar up somewhere then delete, ...). Perhaps something like - deluser snowman does a find and error exits if any files belonging to snowman are found - deluser -f snowman deletes snowman without doing a find, possibly leaving files belonging to deleted user 1234 hanging around, which might someday be inherited by an added user assigned userid 1234. On the presumption that if something needs doing with the files the sysadmin will do it before doing the deluser. Delser (without -f) will warn him if he forgets, and files are in place. If he tells deluser to force the user deletion by saying -f, it'll do that.
Re: changes file format
Ian Jackson writes: James A. Robinson writes (Re: changes file format ): No, that's me whom you are quoting here 847dfb732aa3e994f1917d27ffc20eb3 adduser-1.94-2.deb 70fa124c71e5b709019f6729eb8cfe11 adduser-1.94-2.tar.gz -rw-r--r-- 1 root root13122 Oct 23 18:43 adduser-1.94-2.deb -rw-rw-r-- 1 root ian 24448 Oct 23 18:43 adduser-1.94-2.tar.gz ^ File permissions, link count, ownership an modification times on the maintainer's system are not of general interest, why include them in an announcement? The rest easily fits onto a single line and put the fixed length parts in front. I agree that this is a kludge, and I would write a separate script to produce a less overblown output form. However # md5sum size name 70fa124c71e5b709019f6729eb8cfe11 24448 adduser-1.94-2.tar.gz 847dfb732aa3e994f1917d27ffc20eb3 13122 adduser-1.94-2.deb With fixed length fields the dchanges format will yield a nice readable table and a trivial pipe (left as an exercise to the reader) lets you check the md5sum. this is not good enough. Remember, our release announcements are intended for general consumption and use perhaps even on MSDOS systems, where `a trivial pipe' is a major undertaking. My dos partition contains a port of gawk, no problem to write the pipe :) In either case it's easier to extract needed parts from a single line than to collect them from several lines. We need to be able to feed the announcement to `md5sum -c', which expects checksum space space filename. Just curious, does an msdog version of md5sum grog long filenames? Should the 8.3 filename be included in the announcement to suit msdogs? -- Siggy (the middle S.)
Re: changes file format
Ian Jackson [EMAIL PROTECTED] said: Bill Mitchell writes (Re: changes file format ): [...] I also reiterate my suggestion that we stop the practice of maintainers announcing directly (and prematurely) to debian-changes, and have the maintainer announcements uploaded to debian.org along with the other package files, [...] No, this has even worse security properties than the scheme we have at the moment. [...] I agree that the current situation has security problems. I thought a PGP-based scheme was the pending solution. Anyhow, my point was that the package announcements shouldn't be made directly to the world at large by dthe package maintainer, and made before it's even been decided whether the announced package will be placed in the distribution, as is currently done. Instead, the announcement should be made when the package is placed in the distribution. This should of course be done consistent with whatever security mechanisms we decide to put in place. As an aside, I think we should make some decisions about what the security requirements actually are before we start implementing security measures. There are generally tradeoffs between security level and convenience (or lack thereof), and we ought to make those tradeoffs in a reasoned manner.
e2-2.0.beta-2 uploaded
This is being announced to debian-devel, not to debian-changes. This is beta-test software -- do not put it in the distribution. Please place this package in private/project/BETA. This is for beta test by those debian developers who may be so inclined. Date: Tue Oct 24 22:06:05 PDT 1995 Package: e2 Version: 2.0.beta-2 Description: A text editor, patterned after the unix vi editor e2-2.0.beta is patterned after the vi editor, and provides several enhancements, among which are C language syntax hiliting and an X11 interface with clickpoint positioning, click drag selection, and more. . This is a beta test version, and is expected to have bugs. . The author says, in his README.hmtl file: . This software _will_ break. I know this. The only reason I'm making this version available is so that I can receive bug reports. If you aren't willing to suffer core dumps, and report them to me politely, then _don't_ use this software! Priority: Routine Changes: Update from 2.0e beta to 2.0h beta The following is from the author's announcement. Please report bugs directly to the author at [EMAIL PROTECTED] . There are no really big differences between elvis 2.0h (the new version) and elvis 2.0g (the previous version), but here are the medium-sized differences: . * Bug fix: The tag stack works in the help documents now. . * Bug fix: After :set number, rectangular visible selections should look correct now. In 2.0g, the hilighted region was 8 columns to the right of the real selected area. Also, the cursor used to be displayed in the wrong place if it was on the first character of the buffer; this has been fixed. . * The :map command works in elvis.ini or .exrc files now. In 2.0g it didn't. . * Some linking problems with the stop() function have been fixed. Also, some POSIX systems had trouble with elvis' use of sigaction(); I think I have that fixed now too. . * The z command didn't work correctly in html or man display mode. This has been fixed. . * Under MS-DOS, initialization should work better now. . * Instances of #if defined(__STDC__) || (__cplusplus) have been replaced by #if USE_PROTOTYPES. This was done because many ANSI-plus-extensions compilers don't define __STDC__ when the extensions are enabled. . * When an edit session is restarted, elvis will assume that the filenames for any user buffers are the same as their buffer names. . * When a user buffer is created, its name will be the same as the filename. Previously it was just the basename, but that caused problems if you wanted to edit versions of the same file from different directories. . * If you set undolevels to a value greater than 1, then elvis will use u to undo and ^R to redo, like vim. The circular [count]u style was just too confusing. Also, a :redo command has been added. . * Filename arguments are now subjected to the same sort of calculation as the :eval command. This was done mostly so that environment variables could be expanded in filenames. It also means that parenthesis characters have suddenly become dangerous in filenames. . * The calculator now has two new built-in functions: elvispath(file) which searches through elvispath for a given file, and feature(name) which returns true if the named feature is supported in this version of elvis. Currently the feature(name) function just tests to see if name is the name of a supported display mode. . * Fixed some problems with tag lookup in HTML mode. . * For UNIX, the default config.h file will now indicate whether termcap.h should be #included. This is set automatically, depending on whether the /usr/include/termcap.h file exists or not. . * The x11 interface now supports the selection style of interclient cut paste, as well as the older X11 cut buffer style. This means that you should now be able to cut paste with any application that follows ICCCM guidelines. (Previously, elvis 2.0 only supported the older X11 cut buffers, which allowed cut paste between elvis and xterm, but nothing else -- not even rxvt.) . Elvis can be configured to change the cursor color to indicate whether it owns the selection. :color c red on green will make the cursor green if elvis owns the selection, and red otherwise. . * Fixed a bug in the error message generated when -b is given an invalid block size argument. Previously, elvis would leave the terminal in raw mode. . * The MS-DOS version now
new base
Ian, I have uploaded the following files. Please install them, and then you have my OK to make the release. Note that I made a slight change to your root disk - it now mounts the boot disk read-only instead of read-write. Thanks Bruce 1200_boot_floppy.gz 1440_base_floppy-1 1440_base_floppy-2 1440_base_floppy-3 1440_boot_floppy.gz 1440_root_floppy.gz base-0.93.6-12.changes base-0.93.6-12.deb base-0.93.6-12.tar.gz boot-floppies-0.93.6-17.changes boot-floppies-0.93.6-17.changes.bak boot-floppies-0.93.6-17.deb boot-floppies-0.93.6-17.tar.gz floppies.md5sum
Bug#1744: dpkg: cannot scan updates directory `/var/lib/dpkg/updates/': No such file or directory
I had written: On a newly created (though slightly fudged) debian system, I'm getting the message: dpkg: cannot scan updates directory `/var/lib/dpkg/updates/': No such file or directory when I try and use dpkg (-i or -C, for instance). You replied: Here is the relevant bit of code from dpkg: cdn= scandir(updatefnbuf, cdlist, ulist_select, alphasort); if (cdn == -1) ohshite(cannot scan updates directory `%.255s',updatefnbuf); /var/lib/dpkg/updates/ exists and is empty. /var/lib/dpkg/updates is usually empty when dpkg starts up, so its emptiness shouldn't be a problem. Are you using an odd libc of some kind ? I was indeed using some kind of mix of the libc from the base disks and and libs copied off another debian machine. I'd needed to do this to bring up a debian umsdos system on a laptop. However, at this point I've re-installed libc-4.6.27-6.deb (using dpkg-deb -e and -X and manually running the postinst from the DEBIAN directory), and I still have this problem. It does look like scandir() is the culprit -- and dpkg-deb -I also fails. I've written perl programs which call readdir() on this new system and they seem to work fine, so I have some confidence that this isn't a umsdos filesystem implementation problem (though I'm not ready to cross that off my list either). It would be ideal, for me, if you could re-write dpkg, etc. without scandir. However, I imagine this is going to have to get fixed in libc or some such. I'll see if I can find the source for scandir to expedite this. Oh well... -- Raul
Re: changes file format
[EMAIL PROTECTED] said: Release announcements are prepared in whatever way the package maintainer likes, and submitted in a format that looks like yours. It would be nice if we could use the existing dchanges tool to do this. The announcements are reformatted into a format that looks like mine, before being posted (to the instant-updates list, see below). Fine. I don't really care what the human-readable format looks like if we can use dchanges as the input to the script that produces it. I can write a program to convert between the two formats, so that if you edit your changelog in my format you can generate the release announcement in dchanges format and never have to read it. That's fine. The only thing I think I need to do this is a way to represent a blank line in the dchanges format's Changes field. Didn't you do something like this for the description field in Debian packages? Bruce
Re: changes file format
[EMAIL PROTECTED] said: It's important that the distribution channels for the MD5 checksum information and the files themselves remain separate. (For this reason I think that putting the MD5 checksums in the Incoming directory itself is bad - there should be a separate administrative directory.) This is why I had proposed to PGP-sign the .changes files as a method of verifying their authenticity. The program that processed the .changes files would check them against the purported author's public key. If I understand you correctly, you are proposing to have a write-only upload directory for the .changes files . Bruce
Re: changes file format
Bruce Perens [EMAIL PROTECTED] said: [EMAIL PROTECTED] said: [...] The only thing I think I need to do this is a way to represent a blank line in the dchanges format's Changes field. Didn't you do something like this for the description field in Debian packages? Yes, something was done there, and dchanges adopted it.
Bug#1744: dpkg: cannot scan updates directory `/var/lib/dpkg/updates/': No such file or directory
Ok, so here's how things look to me at present:
dpkg is failing because of an ENOENT error return from scandir(3).
scandir is getting this error value from readdir().
I do not know enough about libc to easily determine whether the
readdir() used by scandir is readdir(2) or readdir(3). However, I
suspect it's readdir(3).
Something is happening in readdir to result in this error condition
for a loop of the form:
DIR *dp= opendir(dir);
while ((d= readdir(dp)) != 0) {
...
}
This implies that readdir is messed up.
Another possibility is that the underlying file system (umsdos) is
messed up. But why does it only fail in scandir()?
Oddly enough perl's use of readdir (sort readdir(D)) in run-parts
seems to have no problems.
I'm not sure, at the moment, how to proceed with this problem.
scandir() fails but readdir() apparently does not, yet readdir is
apparently at fault.
I'm sure I'll be able to eventually figure things out the hard way --
by taking the code apart one step at a time while figuring out how it
works. I'm hoping somebody will be familiar with this class of
problem and be able to just whip out the answer.
If anyone has any suggestions I'd be glad to hear them.
--
Raul
Re: changes file format
Date: Wed, 25 Oct 95 14:05 GMT From: Ian Jackson [EMAIL PROTECTED] File permissions, link count, ownership an modification times on the maintainer's system are not of general interest, why include them in an announcement? The rest easily fits onto a single line and put the fixed length parts in front. I agree that this is a kludge [...] It may be a kludge, but familiarity makes for readability. I can look at ls -l output and immediately obtain the information I need from it. We need to be able to feed the announcement to `md5sum -c', which expects checksum space space filename. I agree completely. At the moment, I have to run a special script to convert the dchanges md5sum format into a format that md5sum -c can understand. This is a pain. If I didn't know how to write a shell script to parse a string and rearrange it, I'd be out of luck.
FTP method for dselect needed
Ian Jackson, Brian White, and The Group, I notice there's still no FTP installation method for dselect. The latest base floppy set that I have uploaded is net-enabled. If dselect were able to do direct FTP, that would make it possible to install the system very easily from an Ethernet-connected system. If nobody else is working on this, Brian White would be an obvious candidate. The dftp program he's already written must contain most of the functionality needed. Thanks Bruce Perens
Bug#1744: dpkg: cannot scan updates directory `/var/lib/dpkg/updates/': No such file or directory
One more bit of information: this problem occurs with libc-4.6.27 -- Raul
Re: changes file format
[EMAIL PROTECTED] said: At the moment, I have to run a special script to convert the dchanges md5sum format into a format that md5sum -c can understand. This is a pain. I'd like to point out that dpkg should verify the package for the end-user. Someone who doesn't know how to write a script should not ever have to run md5sum on a package. Bruce
Bug#1766: Bug in script checksecurity in package cron
Package: cron Version: 3.0pl1 Revision: 20 I have a problem with the script checksecurity, which apparently come with cron. The problem is with the lines that generate the /var/log/setuid.today file (patch follows). Explanation: The mount | grep -v command is the problem for anyone who has more than one partitions mounted; the script actually tries to run find with multiple starting points (which is an error), like find dir1 dir2 dir3 -xdev ... The solution is to look at all the directories discovered by the mount snippet and examine each in a for loop. (This has been one of my more incoherent explanations; feel free to mail me for clarifications). Also, I think one should exclude all mounted systems of type msdos (If nothing else, it save time). manoj __ dpkg -S checksecurity cron: /usr/sbin/checksecurity diff -u -B -b -w /usr/sbin/checksecurity.dist /usr/sbin/checksecurity --- /usr/sbin/checksecurity.distWed Sep 20 20:52:12 1995 +++ /usr/sbin/checksecurity Thu Oct 19 11:05:23 1995 @@ -10,10 +10,9 @@ umask 077 cd / - -find `mount | grep -vE ' type (proc|iso9660) |^/dev/fd| on /mnt' | cut -d ' ' -f 3` \ - -xdev \( -type f -perm +06000 -o -type b -o -type c \) -ls \ - | sort $TMP +for dir in `mount | grep -vE ' type (proc|iso9660|msdos) |^/dev/fd| on /mnt' | cut -d ' ' -f 3`; do +/usr/bin/find $dir -xdev \( -type f -perm +06000 -o -type b -o -type c \) -ls ; +done | sort $TMP if ! cmp -s $LOG/setuid.today $TMP /dev/null then -- ...difference of opinion is advantageious in religion. The several sects perform the office of a common censor morum over each other. Is uniformity attainable? Millions of innocent men, women, and children, since the introduction of Christianity, have been burnt, tortured, fined, imprisoned; yet we have not advanced one inch towards uniformity. Thomas Jefferson, Notes on Virginia Manoj Srivastava Project Pilgrim, Department of Computer Science Phone: (413) 545-3918 A143B Lederle Graduate Research Center Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 email:[EMAIL PROTECTED] http://www.pilgrim.umass.edu/~srivasta/
Bug#1763: sysklogd init script has no links to rcx.d
Andrew Howell writes (Re: Bug#1763: sysklogd init script has no links to rcx.d): Ian Jackson writes: Since the package should not have been renamed (see my recent message on debian-devel) this is all moot, but what should really have been done was just to add the extra `k' to the existing links. Considering it's now in binary/base and probably on the new disk set Bruce is making I wouldn't call it moot. The new syslog package with the `k' in its name should be REMOVED from the distribution and replaced with the old one with the `k'. I said a while ago that it should not be moved into it, and now that it has been it should be removed again immediately. Installing the new package will probably wipe out the user's configuration, including the syslog.conf !! Ian.
