Re: announcement
It looks fine to me. Go for it! Thanks Bruce
Debian GNU/Linux 0.93 Release 6 now available
Debian GNU/Linux 0.93 Release 6 is now available via anonymous FTP from ftp.debian.org in the directory /debian. Release 6 is the first official release of version 0.93, which has been under development for over a year, and it is the first official release from the Debian Project since January 1994. Release 5 of version 0.93, an unofficial BETA release, has been available to the public since March 1995, and has received rave reviews from its users. Debian GNU/Linux includes hundreds of software packages, including most GNU software, TeX, and the X Window System. Each package is an independent and modular unit, in that it is not associated with any particular release of the complete system or distribution scheme. Anyone can create their own packages and even upload them to be made available with the distribution or as a part of the distribution. Of course, Debian GNU/Linux is best known for its upgradability. It is upgradable incrementally and "in place". This means that users can upgrade individual packages or entire systems when they become available without having to reformat and reinstall. A user can choose to upgrade certain new or updated components as they are released, or she can choose to install an entire new release at once. The package maintenance system, called dpkg, makes sure that package conflicts and dependencies are resolved, and it intelligently updates configuration files to preserve any changes the user made before the upgrade process. Debian GNU/Linux 0.93 will be the last release that uses the a.out binary format. Version 1.0 and beyond will use the ELF binary format. As always, Debian GNU/Linux 0.93 will be upgradable to 1.0, without the need to reformat or reinstall. For more information about Debian GNU/Linux, please visit the World Wide Web page `http://www.debian.org/'.
Re: announcement
On Thu, 26 Oct 1995, Ian Murdock wrote: > Should I add anything (for example, about the mirror problems) to the > announcement? Here is what I have thus far. I want to send it in a > few hours, so please speak now or forever (or until the next release, > whichever comes first) hold your peace. > > I would run through the mirrors you have and check it a little bit. Someone plesae mail me a copy of the current ftp.sites or whatever it is called, so that I can update it with my archives of mirror sites.. I will then modify the failure announcement :) when there are too many ftp's with the output of that file. I will also give the status of the ftp sites wether they have a full mirror or a part mirror up down or whatever... >From this day forward until the slump between next releases :) any mirror _caught_ running in "user space" a.k.a. Anonymous are the mercy of a kill -9 PID. If you are still mirroring using anonymous please mail [EMAIL PROTECTED] I will contact you from there. Infact add,to the announcement, that if they want to become a public mirror to mail [EMAIL PROTECTED] or [EMAIL PROTECTED] I will then add this to all needed files. (machine readable/human readable) Maybe for use with a ftp method so it knows where to go so the user can select a local site.. Anyway other than that I would go for it... Matt
pre-inst and post-inst scripts that start and stop daemons
Part of the process of building the base disks involves installing all of the base packages on an "alternate root", that is using the "--root" argument of "dpkg" to set its idea of the root to the directory in which I'm building the base. When I do this, I see a lot of messages about not being able to kill network daemons, /proc not being mounted, etc. Also, daemons are probably being started when it isn't appropriate. However, I do want to execute the pre-inst and post-inst scripts because most of the work they do is useful and necessary to build correct base disks. I think we should agree on an environment variable that I can set to tell the pre- and post-inst scripts not to start of kill daemons. Would "DEBIAN_NO_DAEMONS=1;export DEBIAN_NO_DAEMONS" be an appropriate thing to use? Thanks Bruce -- See Pixar's "Toy Story", at a theatre near you starting November 22.
Re: Debian GNU/Linux 0.93 Release 6 now available
On Thu, 26 Oct 1995, Ian Murdock wrote: Eeekk. earlier than I thought... before you go posting it please get a list of the current VALID mirror sites. Get it so that I don't get pounded on. :) Anyway please write up another announcement to cover the mirror sites I think they should be there.. Matt :) Also, Is there any need for ftp/www stats to be made available I have everything since I rebuilt the ftp server the last time... Anyone interested in these?
Re: announcement
I checked all the mirrors earlier this evening. I removed the ones (at least for the moment) that are incomplete (i.e., not mirroring all of the archive), incorrect, and outdated. You can find this in /debian/README.mirrors. Before you start displaying it from ftpd, I'll trim it down slightly. At the moment, there is an introductory paragraph or two that aren't necessary for this purpose. Please let me know where you'd like me to put this trimmed down version.
Bug#1744: dpkg: cannot scan updates directory `/var/lib/dpkg/updates/': No such file or directory
Raul Miller: "Bug#1744: dpkg: cannot scan updates directory
`/var/lib/dpkg/updates/': No such file or directory" (Oct 26, 18:24):
> There's a problem with the umsdos file system that prevents scandir(3)
> from working right -- it gives ENOENT instead of EOF upon successful
> termination. This occurs because readdir returns ENOENT upon reaching
> the end of the directory. The msdos file system has the same
> problem. Here's a patch:
>
> --- linux-1.3.29/fs/msdos/dir.c.dist Thu Oct 26 18:11:01 1995
> +++ linux-1.3.29/fs/msdos/dir.c Thu Oct 26 18:12:34 1995
> @@ -86,7 +86,7 @@
> filp->f_pos = 0;
> }
> if (filp->f_pos & (sizeof(struct msdos_dir_entry)-1))
> - return -ENOENT;
> + return NULL;
> bh = NULL;
> while ((ino = msdos_get_entry(inode,&filp->f_pos,&bh,&de)) > -1) {
> if (!IS_FREE(de->name)
The above doesn't look like the right fix: -ENOENT may not be the right
value to return, but the above return value is meant to catch a bogus
file position pointer rather than catch the end of the file. A better
error might be -EINVAL for that case (it means that somebody did a seek
with a bad value at some point).
> --- linux-1.3.29/fs/umsdos/dir.c.dist Thu Oct 26 18:11:02 1995
> +++ linux-1.3.29/fs/umsdos/dir.c Thu Oct 26 18:13:51 1995
> @@ -259,7 +259,7 @@
> }
> /*
> Read count directory entries from directory filp
> - Return a negative value from linux/errno.h.
> + Return a NULL to indicate end of file
> Return > 0 if success (the amount of byte written to dirent)
> */
> static int UMSDOS_readdir(
> @@ -284,7 +284,7 @@
> }
> PRINTK (("UMSDOS_readdir out %d count %d pos %Ld\n",ret,count
> ,filp->f_pos));
> - return count == 0 ? -ENOENT : ret;
> + return count == 0 ? NULL : ret;
> }
> /*
> Complete the inode content with info from the EMD file
How about
return count ? : ret;
instead? At the very least a NULL is definitely wrong, as we're
returning an integer, not a pointer.
Linus
Bug#1766: Bug in script checksecurity in package cron
Hi,
I'm sorry, I should have investigated further before firing
off that bug report about checksecurity. There is no problem with
multiple dir arguments to find (which is perfectly legal, as Ian
Jackson pointed out).
The problem was that there were no
/var/log/setuid.{today,yesterday} files on my system, and
checksecurity failed to create them, resulting in a mail message
every time the cron job was run. If such a file is created, maybe
there is no problem, so a generic setuid.today file should be
installed? (From the trace below, you can see that the diff fails if
there is no setuid.today file). Should I file a fresh bug report?
manoj
Here is what I did to check that:
<[EMAIL PROTECTED]:[~]> rm -f /var/log/setuid.today
<[EMAIL PROTECTED]:[~]> bash -x checksecurity.dist
+ set -e
+ PATH=/sbin:/bin:/usr/sbin:/usr/bin
+ LOG=/var/log
+ TMP=/tmp/_secure.21828
+ umask 077
+ cd /
++ mount
++ grep -vE type (proc|iso9660) |^/dev/fd| on /mnt
++ cut -d -f 3
+ find / /dos /usr /usr/local -xdev ( -type f -perm +06000 -o -type b
-o -type c ) -ls
+ sort
+ cmp -s /var/log/setuid.today /tmp/_secure.21828
++ hostname
+ echo melkor changes to setuid programs and devices:
melkor changes to setuid programs and devices:
+ diff /var/log/setuid.today /tmp/_secure.21828
diff: /var/log/setuid.today: No such file or directory
+ [ 2 = 1 ]
<[EMAIL PROTECTED]:[~]> cp /var/log/setuid.yesterday /var/log/setuid.today
<[EMAIL PROTECTED]:[~]> bash -x checksecurity.dist
+ set -e
+ PATH=/sbin:/bin:/usr/sbin:/usr/bin
+ LOG=/var/log
+ TMP=/tmp/_secure.21873
+ umask 077
+ cd /
++ mount
++ grep -vE type (proc|iso9660) |^/dev/fd| on /mnt
++ cut -d -f 3
+ find / /dos /usr /usr/local -xdev ( -type f -perm +06000 -o -type b
-o -type c ) -ls
+ sort
+ cmp -s /var/log/setuid.today /tmp/_secure.21873
++ hostname
+ echo melkor changes to setuid programs and devices:
melkor changes to setuid programs and devices:
+ diff /var/log/setuid.today /tmp/_secure.21873
5c5,6
< 2111 68 -rwsr-x--- 1 root dip 69632 Oct 22 21:27
/usr/sbin/dip
---
> 2098 68 -rwsr-x--- 1 root dip 69632 Oct 24 19:19
> /usr/sbin/dip
[much deleted here]
+ [ 1 = 1 ]
+ mv /var/log/setuid.today /var/log/setuid.yesterday
+ mv /tmp/_secure.21873 /var/log/setuid.today
+ rm -f /tmp/_secure.21873
-- To be sure of hitting the target, shoot first, and call whatever you
hit the target. Ashleigh Brilliant
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/
elf-libg++ bug?
I posted this one to debian-user receiving no sensible response.
Did I omit required flags on the gcc-elf command? If this isn't the case
it's a bug in elf-libg++.
-- Siggy
--- start of forwarded message (RFC 934 encapsulation) ---
Here's a simple C++ program that segfaults unexpectedly.
Maybe I overlooked some required flags (there is no g++-elf command).
The following transcript hopefully contains all relevant information:
bora:~/tmp$ cat /proc/version
Linux version 1.2.13 ([EMAIL PROTECTED]) (gcc version 2.6.3) #17 Thu Oct 19
07:25:57 MET 1995
bora:~/tmp$ cat segv.C
#include
#include
int
main(int, char *[])
{
ifstream is("/proc/stats");
while ( is ) {
String head;
is >> head;
// ...
}
return 0;
}
bora:~/tmp$ gcc-elf -v -lstdc++ -lg++ segv.C
Reading specs from /usr/lib/gcc-lib/i486-linuxelf/2.7.0/specs
gcc version 2.7.0
/usr/lib/gcc-lib/i486-linuxelf/2.7.0/cpp -lang-c++ -v -undef -D__GNUC__=2
-D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=7 -D__ELF__ -Dunix -Di386 -Dlinux
-D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux
-Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) -D__i486__ segv.C
/tmp/cca25281.ii
GNU CPP version 2.7.0 (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/g++-include
/usr/local/include
/usr/i486-linuxelf/include
/usr/lib/gcc-lib/i486-linuxelf/2.7.0/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i486-linuxelf/2.7.0/cc1plus /tmp/cca25281.ii -quiet -dumpbase
segv.cc -version -o /tmp/cca25281.s
GNU C++ version 2.7.0 (i386 Linux/ELF) compiled by GNU C version 2.7.0.
/usr/i486-linuxelf/bin/as -V -Qy -o /tmp/cca252811.o /tmp/cca25281.s
GNU assembler version cygnus/linux-2.5.2l.15 (i486-linux), using BFD version
cygnus/linux-2.5.2l.20
/usr/i486-linuxelf/bin/ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.1
/usr/i486-linuxelf/lib/crt1.o /usr/i486-linuxelf/lib/crti.o
/usr/i486-linuxelf/lib/crtbegin.o -L/usr/lib/gcc-lib/i486-linuxelf/2.7.0
-L/usr/i486-linuxelf/lib -lstdc++ -lg++ /tmp/cca252811.o -lgcc -lc -lgcc
/usr/i486-linuxelf/lib/crtend.o /usr/i486-linuxelf/lib/crtn.o
bora:~/tmp$ ldd segv
libstdc++.so.27 => /usr/i486-linuxelf/lib/libstdc++.so.27.0.2
libg++.so.27 => /usr/i486-linuxelf/lib/libg++.so.27.0.2
libc.so.5 => /usr/i486-linuxelf/lib/libc.so.5.2.7
libm.so.5 => /usr/i486-linuxelf/lib/libm.so.5.0.3
bora:~/tmp$ segv
Segmentation fault
bora:~/tmp$
The program is valid C++, so what's going on here?
- -- Siggy (the middle S.)
--- end ---
Re: pre-inst and post-inst scripts that start and stop daemons
Rather than naming the effect you want, not starting daemons, I would think it better to name the situation, like DEB_BASE_BUILD or something. Now as time goes on, the scripts will be left to do the right thing, for that set of conditions. This, of course, should be documented like nobody's business. Costa Date: Thu, 26 Oct 95 21:38 PDT From: [EMAIL PROTECTED] (Bruce Perens) To: [EMAIL PROTECTED] Subject: pre-inst and post-inst scripts that start and stop daemons Part of the process of building the base disks involves installing all of the base packages on an "alternate root", that is using the "--root" argument of "dpkg" to set its idea of the root to the directory in which I'm building the base. When I do this, I see a lot of messages about not being able to kill network daemons, /proc not being mounted, etc. Also, daemons are probably being started when it isn't appropriate. However, I do want to execute the pre-inst and post-inst scripts because most of the work they do is useful and necessary to build correct base disks. I think we should agree on an environment variable that I can set to tell the pre- and post-inst scripts not to start of kill daemons. Would "DEBIAN_NO_DAEMONS=1;export DEBIAN_NO_DAEMONS" be an appropriate thing to use? Thanks Bruce -- See Pixar's "Toy Story", at a theatre near you starting November 22.
Re: Bug#1737: missing man pages for accouting commands
Dirk, I'm glad you are maintaining this package. I know you contribute a lot more to Debian than I do so please take my comments in the spirit of team feedback rather than a personal afront. My understanding of the role of a Debian maintainer is that we are not called on to always supply the solutions to the problems but to act as a focal point for the status of the package and a contact person for the author. Since few debian package maintainers are also the authors this adds a valuable layer in the system integration and configuration management. In the case of the acct package missing a man page, I don't think it is important that you write one or if the author is dead set against them (which has not been shown to me), but it is important that we keep the information that reminds the author that we think it should have a man page if at all possible. Even if the author were to say, "Don't ask cuz I'll NEVER write one", we should simply maintain the fact the we think there should be one and let it go at that. About your apparent observation that GNU folk do not believe in man pages... I have never heard this expressed in any form other than the personal preferences of some individuals and they did not repressent the majority. Please note that GNU emacs does come with a man page. I think I've made my point and I don't need to go rooting through GNU sources to find man pages to wave inthe air. I do not see info as a replacement for man nor have i heard that it is intended to be one. Info is a great idea for text browsing. It is a fore-runner to hypertext and is very useful. I have always seen it as a different tool for a different job than man. We can discuss documentation philosophies over brew another time. Please re-consider your position on this. Many times package authors feel too busy to be bothered with man pages. Will the author accept a man page if we contribute one? Would you, as the maintainer, mind keeping a man page in the package diffs for debian if the author will not accept it? Would Susan volunteer to write it if we promised to give her tech advice and to critique it for her? I hope you guys can work out something. I will not be around to see your reply since I'm traveling in the middle east for the next 2 weeks. Thanks for the time, Dirk. Costa Subject: Bug#1737: missing man pages for accouting commands Date: Mon, 23 Oct 95 10:38 EDT To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] From: [EMAIL PROTECTED] Susan G Kleinmann writes: Susan> The man page and the info page for 'acct' refer the reader to Susan> acct(5) for additional information. No such page exists. True, but that is a bug in the upstream version that I as the maintainer can't do anything about but writing the man page myself. And I don't have enough time to do so. Any volunteers? Susan> Likewise, there are no man pages for `ac', `accton', `lastcomm', and Susan> `sa'. Even though much of the relevant information is covered in Susan> the texinfo document for `accounting', it would be helpful to have a Susan> man page for each of these commands, even if it said something so Susan> simple as "look in the texinfo document." Well, Debian is a GNU system. And in the GNU world is a preference for texinfo over manpages. Love it or loathe it --- and then do write some manpages. I close this bug now. -- [EMAIL PROTECTED] http://qed.econ.queensu.ca/~edd
Re: pre-inst and post-inst scripts that start and stop daemons
I think the situation I described could be named "cross-installation". There are other cases than building the base where one might want to install to a different filesystem than the one currently running. Thus perhaps CROSS_INSTALL=1 is the flag to use. If I don't hear much objection to that today, I'll cast it in concrete. Thanks Bruce
Bug#1772: boot, root, base disks need entries in ms-dos tree
Package: disks Version: 0.93R6 (Oct 27) There should be a directory ./debian-0.93/ms-dos/disks with 8.3 names for the boot, root, and base disks. Alternatively, the files themselves could be given 8.3 names since (most of the time) they will be used on MS-DOS systems. --Mike
Re: Bug#1737: missing man pages for accouting commands
CD Rasmussen writes: CD> In the case of the acct package missing a man page, I don't think it is CD> important that you write one or if the author is dead set against them CD> (which has not been shown to me), but it is important that we keep the CD> information that reminds the author that we think it should have a man CD> page if at all possible. Even if the author were to say, "Don't ask CD> cuz I'll NEVER write one", we should simply maintain the fact the we CD> think there should be one and let it go at that. Please do not mistake me: I also would like to see a man page acct(5). But we have a way more severe problem with acct as it stands now---it is only partly functional because the 'sa' command cannot compile under the current kernel. The good news is that I am in contact with the author of the upstream package. The bad news that he has seems to be really busy at work and cannot devote a lot of time to the package. His respone time to my mails isn't too impressive either. CD> Please note that GNU emacs does come with a man page. Please compare the amount of information supplied as info pages to that supplied as man pages. Moreover, the emacs man pages is dated April 1994 whereas the info pages are current. Also, the man page contains pointers to lots of stuff in /usr/local/ which reside in /usr under debian. This point could actually be made for quite some manual pages, eg I noticed it for procmail(1) yesterday. I am sure I once saw an explicit statement saying that the GNU operating system will use info as its main source of documentation, but I can't remember where that was. There is a preference for info over man with GNU and the FSF that I take for granted. As you, I don't want to open a debate as to whether info or man is superior. The fact of the matter is that we often have only the one or the other---and inevitably someone will be bothered by this and say "hey, why hasn't the foobar command a man page ?". CD> Would you, as the maintainer, mind CD> keeping a man page in the package diffs for debian if the author will CD> not accept it? That is what I did with the `last', a package derived from the acct package. As I found it unacceptable to force `last' users to install `acct' only for the documentation, I quickly copied the relevant texinfo stuff from the acct texinfo source into a man page that is packaged with `last'. I am sorry that I was rather rough in my reply to the bug report. I did not mean to offend anyone, and certainly not Suzan who reported it along with another one. -- [EMAIL PROTECTED] http://qed.econ.queensu.ca/~edd
Re: pre-inst and post-inst scripts that start and stop daemons
[EMAIL PROTECTED] (Bruce Perens) said: > I think we should agree on an environment variable that I can set to > tell the pre- and post-inst scripts not to start of kill daemons. > Would "DEBIAN_NO_DAEMONS=1;export DEBIAN_NO_DAEMONS" > be an appropriate thing to use? Should each individual maintainer need to worry about this? Should you rely on all individual maintainers having handled this properly? How about localizing the effect of this to /usr/sbin/start-stop-deamon, by putting the conditional daemon start-stop code there? Also, it strikes me that this DEBIAN_NO_DAEMONS variable name is less descriptive than it could be. Since the purpose is to control whether or not daemons are to be started or stopped, perhaps DEBIAN_NO_STARTSTOP_DAEMONS would be a better choice than DEBIAN_NO_DAEMONS. Also, is it necessary to say "DEBIAN"? Are there any such things as "non-debian" daemons? If not, perhaps the "DEBIAN" can be dropped. That leaves us with NO_STARTSTOP_DAEMONS. Also, I wonder about the significance of the "=1". Given the functionality and the variable name, setting it to anything other than "" should probably suppress starting/stopping of daemons. Finally, presuming that the code conditioned on this environment variable is localized to the start-stop-daemon script, the usage of this environment variable should be clearly documented in (at least) the start-stop-daemon(8) man page. My $.02 worth of comments.
Re: pre-inst and post-inst scripts that start and stop daemons
Bruce Perens <[EMAIL PROTECTED]> > I think the situation I described could be named "cross-installation". > There are other cases than building the base where one might want to > install to a different filesystem than the one currently running. Thus > perhaps CROSS_INSTALL=1 is the flag to use. If I don't hear much objection > to that today, I'll cast it in concrete. This strikes me as a bad approach. It implies that whomever interprets that flag must know what a "CROSS_INSTALL" is, and what special action might be required of them to support it. The situation, however, is that some particular session is doing a "cross-installation" operation which requires some special handling. It seems to me to make more sense from an information-hiding perspective to have that one particular session know what specific special actions might be necessary to support "cross-installation", and to arrange for those special actions with whomever is responsible for performing them -- interacting whth individual action-performers in terms of the actions for which that particular performer is responsible rather than in terms of whether "cross-installation" is happening. In other words, I think it'd be better to name the environment variable something like NO_STARTSTOP_DAEMON than CROSS_INSTALL.
Start-stop-daemon feature request to support cross-installation.
> How about localizing the effect of this to /usr/sbin/start-stop-deamon, > by putting the conditional daemon start-stop code there? An excellent idea! That would do 90% of the work for me right away. Ian Jackson still maintains start-stop-daemon, right? Ian, can you make start-stop-daemon a no-op when $CROSS_INSTALL is set? For context, this is for use when cross-installing with "dpkg --root", and daemon manipulation is not appropriate. I will have my script set the variable, it's not necessary for "dpkg" to set it. > The usage of > this environment variable should be clearly documented in (at least) > the start-stop-daemon(8) man page. Right. Thanks Bruce
Re: pre-inst and post-inst scripts that start and stop daemons
I'd be happy to support both "NO_STARTSTOP_DAEMON" and "CROSS_INSTALL". Bruce
Bug#1744: dpkg: cannot scan updates directory `/var/lib/dpkg/updates/': No such file or directory
I (Raul) wrote::
> > --- linux-1.3.29/fs/msdos/dir.c.distThu Oct 26 18:11:01 1995
> > +++ linux-1.3.29/fs/msdos/dir.c Thu Oct 26 18:12:34 1995
> > @@ -86,7 +86,7 @@
> > filp->f_pos = 0;
> > }
> > if (filp->f_pos & (sizeof(struct msdos_dir_entry)-1))
> > - return -ENOENT;
> > + return NULL;
> > bh = NULL;
> > while ((ino = msdos_get_entry(inode,&filp->f_pos,&bh,&de)) > -1) {
> > if (!IS_FREE(de->name)
Linus replied:
> The above doesn't look like the right fix: -ENOENT may not be the
> right value to return, but the above return value is meant to catch
> a bogus file position pointer rather than catch the end of the
> file. A better error might be -EINVAL for that case (it means that
> somebody did a seek with a bad value at some point).
I'm sorry, I didn't pay close enough attention.
However, looking at my documentation on readdir, I think this should
be EBADF.
Me:
> > --- linux-1.3.29/fs/umsdos/dir.c.dist Thu Oct 26 18:11:02 1995
> > +++ linux-1.3.29/fs/umsdos/dir.cThu Oct 26 18:13:51 1995
> > @@ -259,7 +259,7 @@
> > }
> > /*
> > Read count directory entries from directory filp
> > - Return a negative value from linux/errno.h.
> > + Return a NULL to indicate end of file
> > Return > 0 if success (the amount of byte written to dirent)
> > */
> > static int UMSDOS_readdir(
> > @@ -284,7 +284,7 @@
> > }
> > PRINTK (("UMSDOS_readdir out %d count %d pos %Ld\n",ret,count
> > ,filp->f_pos));
> > - return count == 0 ? -ENOENT : ret;
> > + return count == 0 ? NULL : ret;
> > }
> > /*
> > Complete the inode content with info from the EMD file
Linus:
> How about
> return count ? : ret;
> instead? At the very least a NULL is definitely wrong, as we're
> returning an integer, not a pointer.
Oops.
Yes, thanks.
--
Raul
Unanswered problem reports
The following problem reports have not yet been marked as `taken up' by a message to [EMAIL PROTECTED] OVER 8 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 379 mount Repeatable mount(1) problem wi Bill Mitchell <[EMAIL PROTECTED] 416 wenglish perl doesn't flush output auto [EMAIL PROTECTED] 421 term unreasonable restriction on te Raul Miller <[EMAIL PROTECTED]> OVER 7 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 563 tartar -x fails to overwrite or c [EMAIL PROTECTED] (Ian Jackso 579 image (?) missing /usr/man/man8 manpages Bill Mitchell <[EMAIL PROTECTED] 660 gdbGDB gets address of structure [EMAIL PROTECTED] (Ian Jackso 662 procps top doesn't behave sensibly if [EMAIL PROTECTED] (Ian Jackso OVER 6 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 691 textutils textutils package, fmt(1) prog Bill Mitchell <[EMAIL PROTECTED] 702 findutils locate crash with large db Ernie Elu <[EMAIL PROTECTED] 710 xs3X server problem with hardware [EMAIL PROTECTED] (Ian Jackso 713 mh mh should pause after printing [EMAIL PROTECTED] (Ian Jackso 723 xconfigX server default configuration [EMAIL PROTECTED] (Ian Jackso 725 xbase twm places windows incorrectly [EMAIL PROTECTED] (Ian Jackso 729 procps Bizarre corrupted output from [EMAIL PROTECTED] (Ian Jackso 731 ncursesncurses wgetnstr doesn't work [EMAIL PROTECTED] (Ian Jackso 737 gawk gawk references to `$0' in END [EMAIL PROTECTED] (Ian Jackso 740 xbase xclock leaves `droppings' in i Ian Jackson <[EMAIL PROTECTED] 746 cpio mt doesn't support setblk (and [EMAIL PROTECTED] (Ian Jackso 759 kbd, xbase /usr/bin/X11/showfont conflict [EMAIL PROTECTED] (Raul Miller) 773 xbase xmh falls over if mh is not in [EMAIL PROTECTED] (Richard K 775 xbase twm reports errors on incorrec [EMAIL PROTECTED] (Richard K 783 tartar --same-order doesn't work [EMAIL PROTECTED] (Ian Jackso 784 manpages Infelicities in fopen manpage [EMAIL PROTECTED] (Ian Jackso 785 cpio mt problems[EMAIL PROTECTED] (Bill 786 syslogdsyslogd gone awol [EMAIL PROTECTED] (Ian Jacks 797 (base) /etc/termcap console keydefs f Bill Mitchell <[EMAIL PROTECTED] 798 svgalibsvgalib gets control key mucke [EMAIL PROTECTED] (Raul Miller) 808 emacs Info anchors not active in ema [EMAIL PROTECTED] 817 tartar -T /dev/null extracts whol [EMAIL PROTECTED] (Ian Jackso 818 bash bash builtin `echo' doesn't ch [EMAIL PROTECTED] (Ian Jackso 819 tartar should have null-separated [EMAIL PROTECTED] (Ian Jackso 820 tcsh tcsh builtin `echo' doesn't ch [EMAIL PROTECTED] (Ian Jackso 821 shellutils /bin/echo doesn't check write [EMAIL PROTECTED] (Ian Jackso 822 tartar -t doesn't check write err [EMAIL PROTECTED] (Ian Jackso 824 cpio cpio should have non-verbose, [EMAIL PROTECTED] (Ian Jackso 825 trntrn warning messages corrupt t [EMAIL PROTECTED] (Ian Jackso 827 libc or sh who reports wrong hostname (wa [EMAIL PROTECTED] (Christian 835 sysklogd syslogd dies, leaves system un [EMAIL PROTECTED] (William 836 (base) Possible bugs in termcap syste "Emilio C. Lopes" <[EMAIL PROTECTED] 841 ncursesdselect from dpkg 0.93.34 says [EMAIL PROTECTED] (Bill 844 manpages readdir(3) should document str [EMAIL PROTECTED] (Ian Jackso 845 manpages access(2) is ambiguous [EMAIL PROTECTED] (Ian Jackso OVER 5 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 850 indent [indent] option mentioned in d [EMAIL PROTECTED] (J.H.M 853 shellutils `nice' does not do anything[EMAIL PROTECTED] (Ian Jackso 857 gs_bothgs (2.6.1pl4-4) doesn't use /e [EMAIL PROTECTED] (Ian Jackso 860 mount `only root can mount' can mean [EMAIL PROTECTED] (Ian Jackso 864 make make gets MAKEFLAGS wrong [EMAIL PROTECTED] (Ian Jackso 887 xarchieR6 xarchie barfs when ftp closes [EMAIL PROTECTED] 889 info Info 3.1-6 [EMAIL PROTECTED] (Emilio C. 902 lprlpr can't print a PostScript f [EMAIL PROTECTED] (Ian Jackso 903 (base) /dev miscellaney Bill Mitchell <[EMAIL PROTECTED] 911 libc libc causes rsh to fail on com [EMAIL PROTECTED] (Ian Jackso 918 miscutils mkboot and image packages [EMAIL PROTECTED] (Bill 923 xbase xdm failed with `unknown sessi [EMAIL PROTECTED] (Ian Jackso 927 ncurses? dselect display bugBill Mitchell <[EMAIL PROTECTED] OVER 4 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 932 pine Pine over-encodes files and au [EMAIL PROTECTED] (Ian Jackso 933 pine Pine wants to post my email re [EM
Re: pre-inst and post-inst scripts that start and stop daemons
Going to the Shakespeare festival?
Re: Aladdin Ghostscript license
Sale for profit of a CD-ROM including a program governed by the Aladdin Free license is allowed as long as everything on the CD-ROM may be copied and redistributed without further fee for (at least) non-commercial purposes. I.e., as long as everything (both software and documents) on the CD-ROM is governed by a GNU, Aladdin Free, public domain, X-like, IJG-like, or similar license, the Aladdin License allows selling the CD-ROM for whatever price the publisher chooses. If this is not the case for the Debian CD-ROM, a commercial license will be needed. The typical such license for CD-ROMs that are nearly (but not entirely) freely redistributable includes a modest one-time payment, a requirement to include full source code and the Aladdin License on the CD-ROM itself, and a requirement to include a copy of the Aladdin License in printed material accompanying the CD-ROM. If this is necessary, please contact me separately. L. Peter Deutsch
Re: pre-inst and post-inst scripts that start and stop daemons
Go, Bruce of Pixar, and let thy shadow be cast across the concrete ... (just warming up for my trip) Costa To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] (Bruce Perens), [EMAIL PROTECTED] Subject: Re: pre-inst and post-inst scripts that start and stop daemons Date: Fri, 27 Oct 1995 09:01:08 -0700 From: Bruce Perens <[EMAIL PROTECTED]> I think the situation I described could be named "cross-installation". There are other cases than building the base where one might want to install to a different filesystem than the one currently running. Thus perhaps CROSS_INSTALL=1 is the flag to use. If I don't hear much objection to that today, I'll cast it in concrete. Thanks Bruce
Aladdin Ghostscript license
> Sale for profit of a CD-ROM including a program governed by the Aladdin > Free license is allowed as long as everything on the CD-ROM may be copied > and redistributed without further fee for (at least) non-commercial > purposes. OK - that clarifies it for me. I don't see any problem with including it in Debian and on my CD-ROM and the FSF CD-ROM. However, we should probably put this product in the "non-free" directory. That's not appropriately named in this case, but the "non-free" directory is a warning to CD-ROM manufacturers to individualy check the licenses of any package in that directory for appropriateness before they include them on their CD-ROMs. Thanks Bruce -- See Pixar's "Toy Story", at a theatre near you starting November 22.
Re: Aladdin Ghostscript license
Peter and Andrew, Please forgive me for not responding earlier regarding the Aladdin Ghostscript license. The only snag I see here is that Debian will be placed on a CD-ROM and sold for profit by various publishers (I'm one, FSF is one, there are probably a dozen others). It's not clear to me that your license would allow distribution of Aladdin Ghostscript on that disc. In the past, we have solved this problem by getting a specific license to sell the program as part of the Debian distribution or a distribution derived from that distribution. Would that be OK with you? I'd be happy to send you a disc if that sort of license is OK with you. I'll be producing CD-writables this weekend. Thanks Bruce Perens -- See Pixar's "Toy Story", at a theatre near you starting November 22.
Re: Aladdin Ghostscript
> From [EMAIL PROTECTED] Tue Oct 24 17:40:44 1995 > Date: Tue, 24 Oct 95 16:38:42 -0500 > From: "L. Peter Deutsch" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: CDROM license > > [...] > > As it happens, I have already been considering switching from the > Yggdrasil to the Debian Linux distribution for my own use. Yggdrasil > insists on GNU-licensing, so they refuse to include Aladdin > Ghostscript on their CD-ROMs (and also refuse to include kermit), [...] This is not true. Yggdrasil insists on distributing only software which is not any less free than the GNU-license. Kermit is commercial software, requiring payment to Columbia in order to sell it. Any distribution that does include it without paying is breaking the law. The Aladdin Ghostscript Free Public License is only free to the non-commercial sector of the public. "public", according to my Merriam-Webster dictionary is "affecting all the people or the whole area of a nation or state". Whoops. Dan (I no longer work for Yggdrasil, so I'm definitely speaking for myself.) -- Daniel Quinlan Member of the League for Programming Freedom [EMAIL PROTECTED]
Bug#1753: trn recommends, instead of depends
On Tue, 24 Oct 1995, Ian Jackson wrote:
> Bdale Garbee writes ("Bug#1753: trn recommends, instead of depends"):
> > Package: trn
> > Version: 3.6-2
> >
> > It's not clear to me why trn uses 'recommends' for a mail transport
> > and a news article injector, while tin uses 'depends'. I think that depends
> > makes more sense, so I'm filing this against trn.
>
> Recommends is correct. You can read news perfectly happily without
> either a mail transport or a news article injector.
>
> I'll reassign the bug report to tin.
Are you sure this is right? Normal functionality of tin allows the user
to mail a response or the article to an address. Would it be correct for
the system to allow someone to install a package where some of the
functionality is missing? This would surely generate another defect
report.
I suppose recommends is a strong enough relationship that the system
maintainer would realize that some functionality may be missing if a
recommended package is missing.
I will make the change to the tin package.
---
Kenny Wickstrom | gnu - a new generation in s/w devel/support
[EMAIL PROTECTED] | Linux - a much improved Un*x clone
(708)740-4008 | Debian - a Linux distribution setting the
#include |standard for future distributions
Re: Aladdin Ghostscript
> Kermit is commercial software, requiring payment to Columbia in order to > sell it. Any distribution that does include it without paying is > breaking the law. You mean, any distribution that involves a payment, right? If payment is only required in order to sell it, that implies that it can be distributed freely if no payment is involved, right? E.g., distributed freely on the net? > The Aladdin Ghostscript Free Public License is only free to the > non-commercial sector of the public. "public", according to my > Merriam-Webster dictionary is "affecting all the people or the whole > area of a nation or state". Whoops. The AGFPL allows free *use* by anyone. It allows free *distribution* by anyone as long as no payment is required to receive the distribution (and there's even a specific exemption from that for certain CD-ROMs, which is where this discussion started). It does not distinguish between "sectors" or classes of *people*, only between *actions* taken by people. For example, I know that Intel distributes Aladdin Ghostscript (free) on a BBS they operate. Probably this isn't the place to get into a discussion of the relative merits of the GNU and Aladdin licenses. If I make it to the free software conference in Boston in February, I hope to stir up some lively discussion on this topic. --lpd
