Bug#1744: dpkg: cannot scan updates directory `/var/lib/dpkg/updates/': No such file or directory
Raul Miller writes: > 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. There is a rather ropey version of scandir in compat.c, which gets compiled in automatically if `configure' sees that you don't have scandir. Try editing config.h not to define HAVE_SCANDIR and see what happens. Obviously the libc (or kernel - I think they changed the directory reading interface) should be fixed eventually. Ian.
dchanges change suggestions
Bruce and Bill: I'd like you to read the suggestions below in the light of my recent comments on debian-private and see which of them you agree with. Any that you both agree with go ahead and do, Bill, the rest we can talk about :-). 1) Can there be an option to include a pre-prepared piece of text given as a command line argument or on stdin or something as the change info ? This option would imply -n (no edit) and you then need an option which will turn the editing back on again. 2) Can the date please be in RFC822 format, rather than the default `date' output ? Also, you're going to supply dates in local time at the maintainer's address you should include the numeric timezone information as well as or instead of the timezone abbreviation. See the 822-date Perl script I posted recently for how to get this info. 3) Can it be arranged that a `source' field in one of or the first of the .deb files is propagated into the output ? 4) When multiple .deb files are included, could you make the Description field in the dchanges file be something like info - Standalone GNU Info documentation browser texinfo - The GNU Project's documentation formatting system texidoc - Texinfo manual - how to write a Texinfo file (ie, the package name and summary description from each package) ? 5) The manpage says: .deb file specified. The dchanges program provides legal but uninformative defaults for the Packages and Changes fields. These defaults should be revised with more infor- I hope this means "... defaults for the _Priority_ ...". If not, then can the Package field be made to contain something sensible :-). 6) Can you please define what the effect is of multiple .deb files on the Package field ? I suggest a comma-separated list. 7) Can we remove the `binary/base' &c file destination specification ? This information should be provided by the distribution maintainer (and they have to anyway, in the Packages file generator's override file, which can be used for the purpose). In any case, if the distribution maintainer wants to use information from the package maintainer they can use the Section control file field. 8) Can we define a syntax for the Priority field ? I'd like it to be a single word, one of LOW, MEDIUM, HIGH or URGENT, with an optional comment in parentheses. 9) Can we define a `status' field, which is a series of words, space-separated, some with predefined meanings, with an optional comment in parentheses. The predefined meanings would be: ALPHA, BETA - usual meaning stable - this should be put into the stable tree, it is a bugfix or very urgent release only experimental - this is an experimental package which shouldn't go into either release tree. - this should go into the bleeding-edge tree. I don't know what ought to be. "bleeding-edge" ? :-) "new" ? I'm also not too enamoured with the name `status' for this field. `stability' ? 10) I need a command-line option to specify the contents of the priority field. 11) The -w option which warns about unreadable files should be the default (and there should perhaps be a way to turn it off). By default unreadable files should produce a non-zero exit status. Ian.
Bug#1763: sysklogd init script has no links to rcx.d
Date: Wed, 25 Oct 95 22:09 EST From: Ian Murdock <[EMAIL PROTECTED]> Date: Thu, 26 Oct 95 02:44 GMT From: Ian Jackson <[EMAIL PROTECTED]> 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. Sorry--I must've missed your first request. By the time I saw your request, it was too late. That is to say, I'd already replaced the old package with the new one. Does anyone have a copy with the old one that we can use until a fixed package is available?
Bug#1763: sysklogd init script has no links to rcx.d
Date: Thu, 26 Oct 95 02:44 GMT From: Ian Jackson <[EMAIL PROTECTED]> 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. Sorry--I must've missed your first request. By the time I saw your request, it was too late. Could the sysklogd maintainer fix this ASAP? We'll have to rebuild the base diskettes, too, to incorporate the fixed package.
Re: FTP method for "dselect" needed
Bruce Perens writes ("FTP method for "dselect" needed"):
> 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.
True.
> 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.
I'm not clear on how dftp is implemented; this may or may not be
true. I shall describe what the FTP method has to do, and then see
what Brian says.
The FTP installation method will have to do all the usual prompting to
find out where things are, and store them in its method-specific
directory in /var/lib/dpkg.
In the `update' script it will have to go and find the Packages files
in all three subdirectories (debian-current - or possibly another
directory if the user specifies one, non-free and contrib) and feed
them to dpkg, the first with --update-avail and then the others with
--merge-avail.
In the `install' script it will have to recursively descend the
`binary' subdirectory in each of the three trees looking for *.deb
files. Each *.deb file will have to be presented to dpkg --unpack
--. Note that relying on the filename is not good
enough - you'll have to write a script that does hacky things with
named pipes to download enough of the package so that the control info
can be extracted and then abort the transfer if it isn't wanted. I
can help with this if needed. If possible it would be good to invoke
dpkg on several files at once, as this is more efficient, but this
could get very tricky.
When all the *.deb files have been processed, and if it all went
reasonably well, the install script should run dpkg --configure
--pending.
Ian.
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.
Bug#1767: cern-httpd installation
Package: cern-httpd Version: 3.0-4 Bug: installation creates group named `--quiet'. # diff group group~ 2d1 < --quiet::101: I believe the intention here is to create a group named `www-data'. BH
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/
Re: inverse of `adduser'?
p.s. Also I was under the impression that GNU (getopt?) used things on the command line like --rev as option-selectors with option name-completion. I was very surprised to see that `adduser' accepted `--version' as a username! Bill
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
Re: changes file format
[EMAIL PROTECTED] said: > I must urge restraint in automating the process. All packages should > be inspected and moved into the distribution by a human. I am > strongly of that opinion. I bet you'll thank us for whatever automation there is once you decide it's time to have a life again :-) . A script could easily tell you if all files are present, if their size and checksum is correct, and if the uploaders PGP signature verifies correctly. After that, you can inspect the file as you wish, and then run another script to move the files into place. Please tell us what you do to inspect the files. Thanks Bruce
Re: changes file format
Date: Tue, 24 Oct 1995 20:36:23 -0700 (PDT) From: Bill Mitchell <[EMAIL PROTECTED]> 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. This is a bad idea. I don't think we should mandate that a script exist somewhere to parse the machine-readable format and generate a human-readable format from it, when we could just as easily have a format that is both human- and machine-readable and that does not require this extra step. We *must*, however, have a script that maintainers can use to generate announcements. dchanges could be adapted to generate a human-readable format instead of the currently-used format. At the moment, the format it uses appears to contain all of the right information, but it doesn't arrange it in a manner that is easily readable by humans. And while I do agree that it would be a good idea for the archive maintainer (me) to moderate debian-changes to prevent announcements from being distributed before the announced package is moved into public view, I must urge restraint in automating the process. All packages should be inspected and moved into the distribution by a human. I am strongly of that opinion.
Re: changes file format
Ian Murdock <[EMAIL PROTECTED]> >We need to be able to feed the announcement to `md5sum -c', which >expects. > > 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. dchanges implemented the announcement format proposed by Bruce. If I recall, there was a call for discussion, but little input. If I'm still maintaining dchanges I can tweak its announcement file format, given a reasonable definition of the desired format. If Ian J. is going to produce a dchanges replacement, he can address that. BTW, "man md5sum" doesn't say anything about the required format for "md5sum -c".
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
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
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. 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.
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
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.
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
[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
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
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
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 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-
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.
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.
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: 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.
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'?
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#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'?
> : * 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.
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'?
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: 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.
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
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: *
header:package-name " (" package-version ")"
status-flags priority-flags end-of-line
package-name: +
package-version:+
word: *
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: " (" + ")"
| ""
footer:" -- " maintainer-info " <"
maintainer-info "> " rfc822-date end-of-line
maintainer-info: "> +
rfc822-date:
md5sums: ( md5sum " " filename ) +
listing:
See my comments about the ls output in another message.
Ian.
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: 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#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: inverse of `adduser'?
Bill Hogan writes: > Now I have a new user named `--version' that I would like to delete only >I can't seem to find a command that undoes what `adduser' does. > > What is the best way to deal with this kind of situation? Someone should write a `deluser' program and it should get it right... If no-one else volunteers I could give it a shot... * delete user from /etc/passwd and remove their group from /etc/group. Remove their login name from any group membership lines in /etc/group. * delete mail spool file (what if it's nonempty?) * delete home directory. What do we do about saving files? * delete crontab (maybe there'll be something in the atjobs or atspool directory which needs fixing too?) * maybe clean up /var/lib/emacs/lock/* (or should something else be doing this? I have a bunch of fairly old files in there...) * do something sensible with files owned by the user or their group under /var/catman and /var/spool/texmf. * maybe clean up files owned by the user or their group under /tmp and /var/tmp? * what about files owned by this user in other directories? (Shared projects, etc.) * what if the user has processes running? Or a print job queued? Or mail queued? * there should be a man page ;-) Anything I've forgotten? Any NIS issues? (I'm not familiar with NIS at all, which may be a good reason for someone else to do this.) All this business about deleting crontabs, etc, suggests that there should perhaps be a more generalised way of deleting user files in spool directories etc. Perhaps it should run any executables in /usr/lib/deluser with the login name as an argument? As to saving user files, Unixware's deluser has the following... Yes | NoThis argument determines whether or not the user's files should be saved when his or her login name is removed. If Yes is specified, all files in the user's home directory are copied to /lost+found/login_name before the home directory is removed. If No is specified, the files in $HOME are not removed. Perhaps Debian's deluser should have a similar feature, though perhaps with a more sensible command line syntax. Maybe it should be possible to delete everything from the home directory except a .forward file. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
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 ~{PmV>HI~} <[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
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#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#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#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 * Login&Passwd: 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#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
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."
