shells (was Re: IP-aliasing)
On Tue, 6 Aug 1996, Emilio Lopes wrote:
CS == Craig Sanders [EMAIL PROTECTED] wrote:
CS I'd like to see a bourne-like shell with perl-like regexp stuff
CS (mainly sed grep) built in - i'd switch to that in a flash.
People may say it's called ksh93. IMHO, it may seem somewhat
interesting, but I really don't like it. Look likes tcl... :-)
zsh seems to have some of these features.
see http://www.mal.com/zsh/ for full details, but this looks useful:
and a substitution modifier:
% echo $name:s/foo/bar/
bar.c
% ls
foo.cfoo.hfoo.ofoo.pro
% for i in foo.*; mv $i $i:s/foo/bar/
% ls
bar.cbar.hbar.obar.pro
it's only simple substitution, though. no regexp.
(siva-cas) ~$ zsh
% fred=xyz.abc.zzz
% echo $fred
xyz.abc.zzz
lets try a regexp subsitution ala sed:
% echo $fred:s/\(...\).\(...\).\(...\)/\3\2\1/
xyz.abc.zzz
ok. that obviously doesn't work. lets try a different format:
% echo $fred:s/(...).(...).(...)/\3\2\1/
xyz.abc.zzz
nope.
you can string together multiple substitions, though:
% echo $fred:s/abc/111/
xyz.111.zzz
% echo $fred:s/abc/111/:s/xyz/222/
222.111.zzz
% echo $fred:s/abc/111/:s/xyz/222/:s/zzz/333/
222.111.333
zsh looks like it's got nice stuff out of sh/bash, ksh, and csh.
looks useful, but it doesn't get eliminate the need to fork sed and
grep.
hmmm...the substitution facility could be useful for standardising
responses in a case statement:
read yesno
case $yesno:l:s/yes/y/:s/no/n/ in
y) do_yes ;;
n) do_no ;;
*) do_error ;;
esac
it's probably too non-standard to use for debian.{pre,post}{rm,inst} scripts
but i might switch to it for my personal use.
debiandoc-sgml 1.0.3: actually formats documents
Grr, I screwed up the SGML entity catalogue handling so the last version wouldn't work at all unless you happened to be in a directory with a few particular files. -BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Mon, 12 Aug 1996 02:30:24 +0100 Source: debiandoc-sgml Binary: debiandoc-sgml Architecture: source all Version: 1.0.3 Distribution: experimental Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: debiandoc-sgml - Documentation formatting for Debian manuals Changes: debiandoc-sgml (1.0.3) experimental; urgency=low . * Converters work again. Oops. * Lout (and hence PostScript) more space at end of compact list. * Minor markup manual improvements. Files: e51b564a6ea92ec2295491a501f50076 555 text optional debiandoc-sgml_1.0.3.dsc 05d299378bbbf29cdf0c406c36407df4 30842 text optional debiandoc-sgml_1.0.3.tar.gz da10dbdb218d5474048863c172459bc1 22106 text optional debiandoc-sgml_1.0.3_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMg6LWcMWjroj9a3bAQFnbQP+LbZa5OZZ4fAjSMP4piayK/v/gg6rQCBN XXmzHHr3AuFldlaXlIu/n+HCXX5tOvBOutZkyk3ahQXXDep+zIekocfk8H4mup9Q +bcZgOv4Fj/MBMfTxRNQvIaPoEs4ItFoGAM1nqYvfHyQMgyMy6G+mjPxfXkdqn96 88Cu0yhsJb4= =Z5wr -END PGP SIGNATURE-
Re: Conversion procedure for new source packages DRAFT
I wrote: This is my first draft of a quick document saying how to convert an old to a new source package. DO NOT DO ANYTHING YET except read this and suggest amendments. I've thought of something to add to this list: * Check that the description is well-formatted and meaningful and helpful to people wanting to know whether to install a package. Should I put all of this in an appendix to the policy manual ? Ian.
Re: Emacs per-package startup files
Brian C. White writes (Re: Emacs per-package startup files): ... [someone:] So, do these files go in /var/lib/emacs, /etc/emacs, or /usr/lib/emacs/site-lisp, and why? I can set it up and send changes to the emacs package maintainers this weekend if that gets worked out... I'd vote for /usr/lib/emacs/site-lisp. Why? Because /var/lib/emacs is for files that can't be on a read-only filesystem and /etc/emacs is for user config files and the like. /usr/lib/emacs/site-lisp is for something entirely different. It's for the main lisp files (modes or whatever) that a package installs. /var/lib is obviously wrong, as the files aren't changed in normal operation. The files need to be conffiles so that the sysadmin can modify their behaviour, remove them, c, and have their changes respected. So it needs to be in /etc. Ian.
Bug#3952: Less annoyances
'Christoph Lameter wrote:' A wish because of the heavy usage of gzipped files under debian: - Add functionality for less to automatically recognize a gzipped file and view it correctly without having to resort to zless. I have code for that (or you can use most): First set some environment variables in .bash_profile or /etc/profile: export LESSCLOSE=lessclose.sh %s %s LESSOPEN=lessopen.sh %s Then somewhere in $PATH put lessclose.sh and lessopen.sh: $ cat /usr/local/bin/lessclose.sh #!/bin/sh rm $2 $ cat /usr/local/bin/lessopen.sh #!/bin/sh # When the environment variable LESSOPEN is set to refer to this file # (e.g., LESSOPEN=lessopen.sh %s), one can do several interesting # things with pipes (see less(1) for details). Namely, # 1. view any gzipped or compressed file(s) anywhere in the filesystem with #the simple command less filename(s). And you can use less' multiple #file searching and bookmark facilities on the gzipped files! # 2. view a list of compressed and uncompressed files from the same #command prompt (using all of less' multiple file features). # 3. zcat file.gz | less still works. if [ $1 != - ]; then # $1 = - when we are reading standard input gzip -t $1 /dev/null if [ $? -eq 0 ]; then # Is it compressed? zcat $1 /tmp/$$.`basename $1` # Use basename for files in echo /tmp/$$.`basename $1` # other directories fi fi exit 0 -- Christopher J. Fearnley|Linux/Internet Consulting [EMAIL PROTECTED], [EMAIL PROTECTED] |UNIX SIG Leader at PACS http://www.netaxs.com/~cjf |(Philadelphia Area Computer Society) ftp://ftp.netaxs.com/people/cjf|Design Science Revolutionary Dare to be Naive -- Bucky Fuller |Explorer in Universe
Re: des encryption..
Yves Arrouye writes (Re: des encryption.. ):
Ian Jackson writes:
Also I propose to mandate in the policy manual that packages which use
/opt should provide appropriate links or files in
/opt/{bin,lib,man,include,info,doc} and that packages which search
paths must look in /opt too. Comments ? (And see the recent
FSSTND/FHS work on /opt - it's deliberately very vague.)
Should we put /opt/bin before or after /usr/bin by default? (I'd suggest
before).
After, because it will be larger, and because it makes it harder for
an /opt package to accidentally cause problems ?
The sysadmin can always use /usr/local to change which one is run if
they want some different arrangement locally.
Ian.
Bug#4107: emacs leaves stale lockfiles and publishes pathnames
Package: emacs Version: 19.29-3 My /var/lib/emacs/lock directory contains many old lock files. I'm quite happy to believe that the occasional leftover lock is unavoidable, but steps should be taken to clean them up. Furthermore, all the pathnames for the lockfiles are world-readable. This is not what one would expect, and confidential information is not infrequently present in filenames. The best solution might be to put the filename or other information about the file through a cryptographically strong one-way function (eg SHA-1 or MD5) and only include the filename in the file itself (which should be readable only by owner). I don't think all the files should be world-writeable, either. Ian.
Re: Caldera's lawsuit against Microsoft
From: Ian Jackson [EMAIL PROTECTED] I'm just posting here on what's really an irrelevant topic to say that I think it's a very good thing that someone is challenging Microsoft. The terms of the suit require MS to give _Caldera_ details of APIs. Not the general public, just Caldera. MS can still keep them under non-disclosure, and Caldera would have to honor the terms of an NDA approved by the court. So, I'm not sure this does a thing for people who write free software. Bruce
Re: Debian, Linux, the FSSTND, the FHS and BSD
From: Ian Jackson [EMAIL PROTECTED] I lost this argument, chiefly through a combination of poor politics on my part Ian, Don't feel bad that you're not good at politics yet - with my 39th birthday approaching I'm only just beginning to understand it. If you feel you've lost arguments through poor politics rather than through any fault in your logic, it's probably appropriate for us to put someone on the FHS who can maintain the necessary _distance_ required for this sort of argument. We value your services tremendously, and would be happy to see you spend more time on your thesis, dpkg/dselect, etc. ...with which I have very strong disagreements: * The mail spool, /var/spool/mail, is moved to /var/mail. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. * A new directory /usr/libexec is created to hold command binaries used only internally by programs - these are to be moved from /usr/lib and in some cases /usr/sbin. Oddly there is no corresponding /libexec directory. I'd be inclined to live with it. We can do the usual symbolic link hacks for Debian 1.2 to help ease the transition, and remove them for 1.3 . You can sum up anything else you disagree with for us on debian-devel. I will hear argument and set Debian's position on the standard. At the very worst, we would make a partial acceptance and produce a compliance statement that details any areas in which we depart from the standard. Thanks for working on this. I'm sorry, I didn't know you had such a depth of emotional involvement in it. Bruce Perens Debian Project Leader
Re: Documentation formats
From: Ian Jackson [EMAIL PROTECTED] The thing is that I think we need to be able to distribute other [documentation] end-products [than HTML]. HTML is bad for printing, for example, and not ideal if you have a slow machine. Choice is a good thing. Do you have a proposal? I'm not trying to exclude other formats, but I'm trying to arrive at a common denominator, even if it has its detriments. I'm not sure I agree with the slow machine part. That seems to be browser-specific. Thanks Bruce
Re: New package standards - LAST CALL
Miquel: If they don't react [to the request to convert to the new source package] in say 2 weeks, someone else can do it (I'll take some) like David did during the transition from a.out to ELF. Thanks for volunteering! Please make sure to merge the multi-architecture patches while you do that. would it be possible to look for an additional architecture dependant patch? For example, if you have bash-1.14.6-1.dsc bash-1.14.6-1.EXTRA.alpha.diff.gz I strongly prefer only one patch per package. I'd prefer the architecture-specific stuff to be in the one main patch, with ifdefs, etc. if necessary. One reason is that there is rarely a patch to user code that is necessary for only _one_ architecture. Either it's word-size, or endian-ness, or something else that is going to be necessary for ultra-sparc as well as alpha, etc. A second reason is that it's nice for the packager to be able to see all of the Debian changes at once. Otherwise, it would be too easy to make incompatible changes that are only caught when we go to build on the architecture that has its own patches. Thanks Bruce
Re: New package standards - LAST CALL
Ian Jackson: Therefore I propose that unless someone raises a serious problem or issue within the next week or two the new packaging guidelines as described in the draft dpkg programmers' manual, the draft Debian policy manual and as implemented by dpkg 1.3.x, will become official. I delegate fiat power to you for the issue of the source package format. Make it final when you feel it's ready. Thanks Bruce
Bug#4118: xosview doesn't use XUSERFILESEARCHPATH
Package: xosview Version: 1.3.2-6 The program doesn't access the directories listed in XUSERFILESEARCHPATH but it does read the default file in /usr/lib/X11/app-defaults.
Re: Debian, Linux, the FSSTND, the FHS and BSD
Ian Jackson writes: The latest draft FHS, which they may well publish as it stands, makes the following changes with which I have very strong disagreements: * The mail spool, /var/spool/mail, is moved to /var/mail. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. I don't like either of these and IMO we shouldn't change. At least not in the near future. * A new directory /usr/libexec is created to hold command binaries used only internally by programs - these are to be moved from /usr/lib and in some cases /usr/sbin. Oddly there is no corresponding /libexec directory. Sounds like a good idea for me. Since you once lobbied for this dir, why don't you like it now? The two good changes that I see are (and they are not minor): * /usr/share exists and is defined. * /opt exists and is defined. Sounds okay, too. Couldn't we make only the changes we like? Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Bug#3961: 14 character file name limit in zoo
Good morning Carl! }Package: zoo }Version: 2.10-1 } }Zoo seems to have some 14 character filename limits, even though the ext2 }filesystem doesn't have such a limit. I can store long filenames, but }an extract seems to truncate the name at 14 characters. I have an a.out }version that doesn't seem to have the same problem, but I am not sure }if I had compiled it, or had gotten it from a very old slackware install. As zoo comes from DOS I'm not sure if it would be a good idea to support long filenames. Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / Never trust an operating system you don't have source for! /
Bug#4118: xosview doesn't use XUSERFILESEARCHPATH
Package: xosview Version: 1.3.2-6 The program doesn't access the directories listed in XUSERFILESEARCHPATH but it does read the default file in /usr/lib/X11/app-defaults. I know, it's a horrible programme, isn't it. Any suggestions about what I can do about this -- it's really not just what paths it searches, it's also how it parses the appdefauls files (all manually). So if you've got any better ideas, I'd like to close this bug. But thanks for the bug-report anyway, it's nice to know people use xosview. -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Bug#3185: NCR SCSI 810 support lacking in bootdisks
Good morning pieterb! }I came to the same conclusion while upgrading my Linux system to }Debian 1.1.2. I also must say that the special-kernel directory in the Debian/stable }directory is a mess in most ftp directories (even in ftp.debian.org). } }Can you send me info if NCR SCSI 810 support is ready in a Debian }bootdisk. Both aha 2940 and NCR 810 are not supported by Debian bootdisks. I was in the same situation and created a special bootdisk, you might want to use it, too. You'll find it in ftp.infodrom.north.de/pub/Linux/Distributions/Debian/goodies/disks-i386/boot1440.bin. There are only modules missing, just skip that section. Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / Never trust an operating system you don't have source for! /
Bug#4049: access permissions for sysklogd
Good morning Daniel! }/sbin/klogd and /sbin/syslogd should be 755. Why? I don't see any reason they should be executable by everyone. I have copied those permissions from my predecessor and I agree to them. }/usr/doc/sysklogd should be 644. Oups, sure. Will be fixed. Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / Never trust an operating system you don't have source for! /
Re: Releases other than by the package maintainert
(b) that the non-usual-maintainer releases should use a particular revision format: eg, hello-1.3-8 would become hello-1.3-8.1. Seems very right to me. But I would like to add the following to it. When mainstream is updated, hello-1.3 - hello-1.4 Non-usual-maintainer updates, hello-1.3-8 - hello-1.4-0.1 Usual-maintainer updates, hello-1.3-8 - hello-1.4-1 Usual-maintainer should never use -0 for revisions. And if we agree on this, it should be mandated in the manual. Erick sorry for cc
Re: sysv `news' package is unclear
No, i mean sysnews. For two reasons: a) it is not sysv specific (you will find it on *bsd as well) b) thats how the package used to be called before i renamed it to news Later, Dominik
Re: New package standards - LAST CALL
You (Bruce Perens) wrote: Miquel: If they don't react [to the request to convert to the new source package] in say 2 weeks, someone else can do it (I'll take some) like David did during the transition from a.out to ELF. Thanks for volunteering! Please make sure to merge the multi-architecture patches while you do that. Why do you think I'm volunteering :) I have ported all the base packages to Debian/Alpha and there are a lot of diffs to merge in anyway. It's probably easier for me to repackage everything and upload it then to get all the maintainers to accept my patches. Well faster anyway. As an added bonus all these packages then have GNU libc support so when libc6 comes out for the i386 it will be just a matter of recompiling. Expect the first Debian/Alpha machine on the net later today or tomorrow ! Mike. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Bug#3961: 14 character file name limit in zoo
As zoo comes from DOS I'm not sure if it would be a good idea to support long filenames. If this is a valid argument for you you might restrict to 8.3 . E
Re: Debian, Linux, the FSSTND, the FHS and BSD
You (Michael Meskes) wrote: Ian Jackson writes: The latest draft FHS, which they may well publish as it stands, makes the following changes with which I have very strong disagreements: * The mail spool, /var/spool/mail, is moved to /var/mail. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. I don't like either of these and IMO we shouldn't change. At least not in the near future. We could ofcourse put in some symlinks (/var/state - /var/lib, etc). Just three of 'em and we'd be compliant :). One problem I see, one way or the other, is how is dpkg going to deal with this? I understand it has some trouble with files in symlinked directories or is that solved now? BTW. I'd prefer going along with the FSSTND at the moment that other distributions do it too. Can't we just wait and see what RedHat and others do? Even better, can't we discuss this with them (hmm Eric Troan isn't on this list is he :)). Mike. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
modules_2.0.0-8
-BEGIN PGP SIGNED MESSAGE- Date: 12 Aug 96 10:47 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Michael Meskes [EMAIL PROTECTED] Source: modules Version: 2.0.0-8 Binary: modules Architecture: i386 source Description: modules: Linux module utilities. Changes: modules (2.0.0-8) base; urgency=HIGH . * Make depmod work again (Bug#4095) Files: 61cf69e4e8d118d137ba7bf3f4327916 111725 base - modules_2.0.0-8.tar.gz 4bf9c38f7090d806cdfd7c5420fd7a3e 9590 base - modules_2.0.0-8.diff.gz 40efc460401ca8e8f2460b6f47e2288e 77514 base required modules_2.0.0-8_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMg8MCipaNcQEtuj1AQFPcAP/T1U9zSof6rgFNCcD8quv504nDb46bbOJ N1IFIx/4jsQTjIkoXkt9XbQGe+kyx03EvIZ6aY2xEbclmm1pF1zSxa3vQInrp44a /skGCKjXbkTBEhjcqNVG6Qeu3SQovo8TJFjJEfLCF/GG7AD6ZL7eJek7hyPuQTaJ WZmhTD4DHFQ= =SN9V -END PGP SIGNATURE- -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Shared library dependencies revisited
Please read the proposal below and comment on it. If noone says
anything I'll probably implement and mandate something very like it in
the next week or two, in time for the new source package format (we
only want to change this once). Now is the time to have your say.
I've been thinking about shared library dependencies some more and
have come to the conclusion that the current scheme is not good
enough. As the new source format spec stands every package which
depends on a shared library must have hardcoded into the
debian/control which shared libraries are involved - the names and
version numbers of the packages must be entered manually into the
Depends or Recommends fields.
This will mean, amongst other things, that when we move to libc6 we
won't just be able to recompile the packages - we'll have to edit the
control files too. This is already causing the alpha people problems
because their libcs are different.
I propose the following arrangement (if you don't understand things
you should read dpkg-source(1) and the relevant parts of the new
programmers' manual):
Every package which contains compiled binaries invokes, in its
debian/rules, a program which automatically determines what the
dependencies are. Eg,
dpkg-shlibdeps -fPre-Depends main/dpkg dselect/dselect
This produces on stdout something like
shlib-Pre-Depends=libc5 (= 5.2.18-2), ncurses3.0 (= 1.9.9e-1)
(The -fpre-depends option can be -fDepends, -fRecommends or even
-fSuggests to specify a particular level of dependency, and
-f... options can be mixed with binary arguments).
The debian/rules puts the output in debian/substvars. Then when it
runs dpkg-gencontrol the main source control file can say:
Source: dpkg
...
Package: dpkg
Pre-Depends: ${shlib-Pre-Depends}
...
The dpkg-shlibdeps program works as follows: it runs ldd on the binary
in question, finding out which libraries are being loaded. It uses
dpkg --search to find which packages they are in. It then looks in a
file provided by that package to find out what the dependency name
ought to be (for example, libX11.so.6 is in xlib but the dependency
name should be elf-x11r6lib) and what version is required to make
ld.so not complain. The file has lines looking like
libname.so.soname dependency
eg
libX11.so.6 elf-x11r6lib
libc.so.5 libc5 (= 5.2.18-2)
I'm not sure where to put the package-provided file. Three
possibilities come to mind:
* /etc/dpkg/shlibs/package
* /usr/lib/dpkg/shlibs/package
* /var/lib/dpkg/info/package.shlibs (came from DEBIAN/shlibs)
/etc has the feature that it can be a conffile, though it's not clear
to me whether this is necessary. The second and third options seem
much of a muchness to me, but I'm inclined towards the /var/lib/dpkg
location as this will effectively hide the real location from anyone
but dpkg (the package maintainer puts the file in DEBIAN/shlibs and
dpkg-shlibdeps is the only thing that needs to find it).
There ought to be a conffile /etc/dpkg/shlibs.default which contains
overriding entries (and can be used to avoid problems when the shared
library in question didn't come from a Debian package, for example
when bootstrapping).
Ian.
Bug#4119: chgrp not detecting error, causing unpredictable results
Package: fileutils Version: 3.13-1 When running chgrp as root, no errors or warnings are given when the group doesn't exist (e.g. when accidently using chown's user.group syntax), but the group is changed to a nearly unpredictable value. Script started on Sat Aug 10 15:36:27 1996 zensunni root 15:36:28 ~/tmp # id uid=0(root) gid=0(root) groups=0(root) zensunni root 15:36:32 ~/tmp # touch demo zensunni root 15:36:37 ~/tmp # ls -l demo -rw-r--r-- 1 root root0 Aug 10 15:36 demo zensunni root 15:36:41 ~/tmp # chgrp an.error demo zensunni root 15:36:54 ~/tmp # ls -l demo -rw-r--r-- 1 root sys 0 Aug 10 15:36 demo zensunni root 15:36:58 ~/tmp # chgrp --help Usage: chgrp [OPTION]... GROUP FILE... Change the group membership of each FILE to GROUP. -c, --changes like verbose but report only when a change is made -h, --no-dereferenceaffect symbolic links instead of any referenced file (available only on systems with lchown system call) -f, --silent, --quiet suppress most error messages -v, --verbose output a diagnostic for every file processed -R, --recursive change files and directories recursively --help display this help and exit --version output version information and exit zensunni root 15:37:06 ~/tmp # chgrp -c an.error demo group of demo changed to an.error zensunni root 15:37:26 ~/tmp # ls -l demo -rw-r--r-- 1 root adm 0 Aug 10 15:36 demo zensunni root 15:37:30 ~/tmp # chgrp -c -v an.error demo group of demo changed to an.error zensunni root 15:37:39 ~/tmp # ls -l demo -rw-r--r-- 1 root tty 0 Aug 10 15:36 demo zensunni root 15:37:42 ~/tmp # exit Script done on Sat Aug 10 15:37:47 1996 Additional information: - when running chgrp as an ordinary user and specifying a non-existant group, an error message is likely to be given, e.g. zensunni ray 15:41 /tmp touch blech zensunni ray 15:41 /tmp chgrp blub blech chgrp: you are not a member of group `blub': Operation not permitted Exit 1 zensunni ray 15:41 /tmp grep blub /etc/group Exit 1 A better message would be: `blub': no such group, but at least an error is given. Educated guess of cause: This is an upstream bug. chgrp's parse_group (chgrp.c:123) is designed to handle numeric gids too. For this purpose, xstrtoul is called (line 138) which returns 0 for OK, or an error value (defined in lib/xstrol.h). Only one of the possible error values (LONGINT_OVERFLOW) causes chgrp to exit with a fatal error. This explains why the problem doesn't often manifest itself when chgrp is run as an ordinary user: ordinary users are members of only a few groups, and are not allowed to chgrp to a group that they are not a member of, including numerical gids not in /etc/group. The interpretation of the group argument as a numerical gid is unlikely to be that of a group of which the user is a member. Ray -- Cyberspace, a final frontier. These are the voyages of my messages, on a lightspeed mission to explore strange new systems and to boldly go where no data has gone before.
Bug#4076: shadow-package (not a deb-format-archive)
On Sat, 10 Aug 1996, Ian Jackson wrote: Michael Gaertner writes (Bug#4076: shadow-package (not a deb-format-archive)): Package: shadow Version: 960530-1 with dpkg 1.2.13elf: ./shadow_960530-1_i386.deb prints: dpkg-deb: 'shadow...' is not a debian format archive Did you download it in binary mode ? It looks OK on the mirror here. If your file is corrupted could you send it to me, uuencoded, and I'll try to make dpkg-deb spot this rather common mistake. Sorry, I rm'd it. Ian. The maintainer can close this bugreport. I got a fresh one from feivel.informatik.rwth-aachen.de and this time all works well. Michael Gaertner [EMAIL PROTECTED] Tel/Fax +49-761-32684
metamail_2.7-5
-BEGIN PGP SIGNED MESSAGE- Date: 12 Aug 96 10:49 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Michael Meskes [EMAIL PROTECTED] Source: metamail Version: 2.7-5 Binary: metamail Architecture: i386 source Description: metamail: An implementation of MIME. Changes: metamail (2.7-5) mail; urgency=LOW . * Made postinst and prerm scripts use the --quiet option Files: 5b4c8b616cc20d34832c3ddb00fc5786 172275 mail - metamail_2.7-5.tar.gz 0172f5607c12b3e2f6c97016243b1a17 50310 mail - metamail_2.7-5.diff.gz cce1ec09117c4c77b728733285ddbc8e 147820 mail optional metamail_2.7-5_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMg8MjipaNcQEtuj1AQEtDAQAiiJ/KXpqf9hEQOOpfjh352WR2yxRVy2I Hzj+3yTPFrKRHS+XfG9eWwKAoIhUiUQmysSCoMAfnEbYBXlhM2EGlnX8+zXlp3SS f7/UnNreHWqnADYGI6Pv+fBrPrxbZa6d10E0rHv66A2Y9xwXU8Yv3vcfTNpCElNg 2gX+jSVATfA= =fhqE -END PGP SIGNATURE- -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
New Ical Package
Date: 12 Aug 96 15:25 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: David Engel [EMAIL PROTECTED] Source: ical Version: 2.0p2-2 Binary: ical Architecture: i386 source Description: ical: An X11/Tk Calendar application - Some of Ical's important features are --- - * Items can be created edited and deleted easily. - * Items can be made to repeat in various ways. - * Ical will post reminders for upcoming appointments. - * Ical can print and list item occurrences. - * Ical calendars can be shared by different users. Changes: Converted to use the shared libg++. . Added support for multiple architectures and new packaging standards (Bug#4113). Files: 87e29ce1ed6a3590f505d71b45cf5b7c 268731 misc - ical_2.0p2-2.tar.gz ce3edae7bfde638bb66a7b7185c40dd0 2314 misc - ical_2.0p2-2.diff.gz 6a5576c4bbb5c32775a665b3b30234ce 152140 misc extra ical_2.0p2-2_i386.deb -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Bug#4120: rdist ssh
Package: netstd
Version: 2.06-1
Currently the netstd package contains rdist version 6.1.
Could this please be upgraded to version 6.1.1 or 6.1.2,
so that it works with ssh?
Thanks.
--
From the ssh FAQ:
4.4 Can I use rdist with ssh?
Stock rdist 6.1.0 does not work together with ssh, due to bugs in it. The
6.1.1 versions of rdist and
later versions are believed to work.
If you use rdist, don't forget to compile the path to ssh into it.
Alternatively, you may specify the -P
option so rdist uses ssh, and not rsh.
If you use password authentication with rdist 6.1.2, you will need to apply
the following patch to
rdist to make it work:
--- src/rshrcmd.c.orig Tue Jun 11 16:51:21 1996
+++ src/rshrcmd.c Tue Jun 11 16:52:05 1996
@@ -63,7 +63,7 @@
/* child. we use sp[1] to be stdin/stdout, and close
sp[0]. */
(void) close(sp[0]);
- if (dup2(sp[1], 0) 0 || dup2(0,1) 0 || dup2(0, 2) 0) {
+ if (dup2(sp[1], 0) 0 || dup2(0,1) 0) {
error(dup2 failed: %s., SYSERR);
_exit(255);
}
Re: Debian, Linux, the FSSTND, the FHS and BSD
Ian Jackson wrote: The latest draft FHS, which they may well publish as it stands, makes the following changes with which I have very strong disagreements: * The mail spool, /var/spool/mail, is moved to /var/mail. This is a positive thing. Both SVR4 and BSD 4.4 put it here. I think any contemporary unix should. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. * A new directory /usr/libexec is created to hold command binaries used only internally by programs - these are to be moved from /usr/lib and in some cases /usr/sbin. Oddly there is no corresponding /libexec directory. I don't really care about these. They're the sort of thing that dances around from one unix to the next anyway. The two good changes that I see are (and they are not minor): * /usr/share exists and is defined. * /opt exists and is defined. These are nice. [1] When the original FSSTND was created I argued in favour of /libexec and /usr/libexec, but lost that debate. I'm less convinced now than I was then, but my main reason for opposing it now is that it is too late to change. Nah - we've always got to be careful about it's too late now syndrome. To think otherwise, is to plot a path to obsolescence. They oughta add /libexec, tho. Symlinks help, especially if you keep developers informed that usage Of those symlinks is deprecated.
Re: Caldera's lawsuit against Microsoft
The terms of the suit require MS to give _Caldera_ details of APIs. Not the general public, just Caldera. MS can still keep them under non-disclosure, and Caldera would have to honor the terms of an NDA approved by the court. I noticed this too. It could just be necessary to make the lawsuit plausible, but I'm not so sure. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Shared library dependencies revisited
I propose the following arrangement (if you don't understand things you should read dpkg-source(1) and the relevant parts of the new programmers' manual): Every package which contains compiled binaries invokes, in its debian/rules, a program which automatically determines what the dependencies are. Eg, dpkg-shlibdeps -fPre-Depends main/dpkg dselect/dselect This produces on stdout something like shlib-Pre-Depends=libc5 (= 5.2.18-2), ncurses3.0 (= 1.9.9e-1) (The -fpre-depends option can be -fDepends, -fRecommends or even -fSuggests to specify a particular level of dependency, and -f... options can be mixed with binary arguments). And what about packages that depend on *one* particular version of a library? I know of one library which will cause trouble, namely libslang. This library changes every minor version update so that programs compiled with earlier versions will not work (I'm not into shared libs, but I think I'm correct if I say that the ABI changes not only with .so-name changes). Maarten ___ | Maarten Boekhold, Faculty of Electrical Engineering TU Delft, NL | | [EMAIL PROTECTED] [EMAIL PROTECTED] | ---
Re: search engines
I've been thinking about what you said regarding search engines for debiandoc. As I understand it, this is to be a debian package, is it not? At least Debian. I won't get upset if someone ports it to Red Hat, Slackware, *BSD*, or a Cray... :-) Cray Linux. I've heard somebody is actually working on that! What do you think of this idea? Thanks for the offer, but alas, it's not workable -- the index needs to be rebuilt for each system separately, since the set of documents is different on each system, and Debiandoc is supposed to support locally installed documentation as well. I will, however, make debiandoc and ferret work together, if it isn't too much work. From my experiments with glimpse a long time ago, it can index arbitrary directories or files, and outputs a list of filenames as the result of the search. If ferret can do that, then I'll add support for it in debiandoc. It shouldn't be hard. Ferret indexes an arbitrary list of words against an arbitrary text string. (The text string is usually a URL or a path name, but it isn't limited to such.) If you could add ferret to the suggests field, I'd appreciate it. Brian ( [EMAIL PROTECTED] ) P.S. I was joking about the Cray Linux thing. :-) --- In theory, theory and practice are the same. In practice, they're not.
