Re: Ian Jackson, please get me the hell off your blacklist.
On Wed, 29 Mar 2000, Branden Robinson wrote: Mar 29 15:20:15 apocalypse sendmail[7886]: e2T8qEi03048: [EMAIL PROTECTED] .greenend.org.uk, ctladdr=branden (1000/1000), delay=11:28:01, xdelay =00:00:21, mailer=esmtp, pri=6332789, relay=chiark.greenend.org.uk. [195.224.76.132], dsn=4.2.0, stat=Deferred: 450 Site not yet trusted, try later [Irritated] Maybe you'd care to explain to me what's not trusted about my site? See http://www.chiark.greenend.org.uk/~ian/sauce/. Note that the response from chiark said 450 Site not yet trusted, try later. First of all, note that it's a temporary failure (450) and your MTA should retry automatically. Also the text says not yet and try later, both of which suggest that the message will be accepted at some point in the future. Irritated? *YOU'RE* irritated? If you don't correct this at once I will be forced to re-evaluate my place within a project that is nominally devoted to free and open communication among its members and the rest of the world. All of the recent discussion about various blacklists, dial-up user lists, etc. seems to have frayed people's tempers. I see a lot of messages from angry people, with little useful content. I suggest everyone takes a step back and thinks before sending further mail: do you really want to waste time arguing about this, and flying off the handle for no good reason? Steve Early
Bug#4557: Last file on iso9660-image always corrupted
Winfried Truemper writes: This error can be reproduced as follows: bash bash mount -t iso9660 -o loop=/dev/loop0 cd /mnt Have you checked to make sure that this isn't a problem with the loopback filesystem? I will test mkisofs on a raw disk partition shortly; I can't do so just yet because I don't have a partition free. Steve Early
Re: Diffs-only for XFree?
In article [EMAIL PROTECTED] you write: I noticed that in the rex/source archive there is currently only the complete XFree-3.1.2 source tree. Are there any means to get ahold of just the Debian specific diffs for it, even if they are quite a lot? We need to get X11 for m68k debianized, but having to extract the changes that were made from the complete source tree myself is..somewhat dumb if there is another way. Debian-specific diffs were hard to produce under the old scheme of things because of the strange way in which the upstream source was packaged. The version of the X packages that I will release in the new source packaging format ought to be a lot more usable. I assume you don't use XFree86 itself on the m68k platforms, and you just want to look at the packaging style? Steve Early [EMAIL PROTECTED]
xsnow-1.40-1
-BEGIN PGP SIGNED MESSAGE- xsnow (1.40-1); priority=LOW Package: xsnow Version: 1.40 Package_Revision: 1 Maintainer: Stephen Early [EMAIL PROTECTED] Description: Snow in your X server xsnow brings Christmas to your X server. A nice waste of CPU time... Changes: * copyright clarified by the author, and a couple of typos corrected 7666a79f944257968e95c8c8874ca05c xsnow-1.40-1.deb 3cc5de66a56659521ac3927e3ea6f2b2 xsnow-1.40-1.diff.gz bfdf257e6a83ad4c87f9cafc40a86d9a xsnow-1.40-1.tar.gz - -rw-r--r-- 1 root root14140 Jan 4 12:37 xsnow-1.40-1.deb - -rw-rw-r-- 1 sde1000 sde1000 4651 Jan 4 12:37 xsnow-1.40-1.diff.gz - -rw-rw-r-- 1 sde1000 sde1000 36001 Jan 4 12:37 xsnow-1.40-1.tar.gz -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMOvKt4li3Xs+7S0lAQGYmwP7B9iw5KBlyRMmkLavqXhLXsWoFvoTFnup TaHg6HfgmYWRE1akoerwg97CXHzpiw+/aHKcH44I8062dEj3Lz41vrcLBLaE4g8d fNUnvOO2FbnnoZmjUXh7ArEIUz7v8ZuKdSnhgynIkbq6ZDVeOwNZsKqRcw8GZNLx 9xET8VQASzU= =8FQu -END PGP SIGNATURE-
Re: what do the X11R6 virtual package names *really* mean?
On Mon, 1 Jan 1996, Mark W. Eichin wrote: standards/virtual-package-names-list.text lists: X11R6 XFree86 R6, including base system xR6shlibXFree86 R6 shared library only I've put together a package of xterm_color (an xterm that supports ANSI color) and used a Depends: xbase; it appears that it should have used Depends: xR6shlib, or possibly X11R6 -- since it relies on the NLS config files (if they exist?) and existing XTerm app-defaults file, I suspect the latter, but thought I'd check for clarification. If it depends on pre-existing app-defaults files (which is probably not a good idea - maybe you should patch it to look for its own app-defaults file) then it should depend on X11R6. For a.out format packages, that's sufficient. ELF X packages should depend on libc5 (obviously) and elf-x11r6lib (a slightly awkward package name that I had to retain for compatibility with the interim elf-x11r6lib package). I'd better get around to updating the virtual packages list soon. Steve Early [EMAIL PROTECTED]
Bug#2061: xbase-3.1.2-5 fails install on 0.93R6 system
On Fri, 22 Dec 1995, Bill Mitchell wrote: Package: xbase Version: 3.1.2 Package_Revision: 5 Installation of this package fails in preinst on a newly-installed 0.93R6 system because /usr/bin/X11 and /usr/lib/X11 do not exist. The patch below corrects this problem. However, with this patch installed, the package goes on to fail installation as follows: Script started on Thu Dec 21 17:32:13 1995 root:x11# dpkg --install xbasewtm.deb (Reading database ... 12018 files and directories currently installed.) Unpacking xbase (from xbasewtm.deb) ... dpkg: error processing xbasewtm.deb (--install): unpick of dpkg-deb tar output failed (-1) for unknown reason: No such file or directory Errors were encountered while processing: xbasewtm.deb root:x11# exit Script done on Thu Dec 21 17:33:04 1995 Are you sure that you have an uncorrupted copy of the package? Check its md5sum against the original announcement. The 'No such file or directory' error is generally only seen when the package file is corrupt. ! if [ -e /usr/bin/X11 -a ! -L /usr/bin/X11 ] Noted - this is a bug, but is unrelated to the problem described above. I presume that you had not previously installed any X packages on this 0.93R6 system; this is a situation that I was not easily able to test. Steve Early [EMAIL PROTECTED]
Re: Linux Kernel 1.3.47 Uploaded
On Wed, 20 Dec 1995, Simon Shapiro wrote: 2. I'd like to throw away the 387 emulation for the compiled kernel. Anyone knows why I should keep it there? I do not believe it to be necessary for the installation, but i have been wrong before. The kernel will not boot on systems that don't have co-processors (eg. 386, 486SX, ...) unless co-processor emulation is compiled in. Steve Early [EMAIL PROTECTED]
Bug#2040: xserver-mach32 won't do 1024x768x16bpp...
On Sun, 17 Dec 1995, Michael Alan Dorman wrote: This is a documented bug in the original source---I believe I sent a patch that could be used to create a xserver-mach32x or something that would be compiled to allow users who wanted to to drive their cards at something resembling its capabilities. Yes, I've dug out my copy of your patch. I'll try and include it in the X packages; the problem is going to be persuading the makefiles to produce the original version of the server as well as the patched one. I'll close the bug report once I've done this. Steve Early [EMAIL PROTECTED]
ftp.debian.org mirror available in UK
I have a mirror of ftp.debian.org on my machine which I am willing to make available to people in Europe. The mirror is available by anonymous ftp to myrddin.chu.cam.ac.uk This mirror will only be available until June 1996. Steve Early [EMAIL PROTECTED]
Re: /etc/X11/Xresources (xbase-3.1.2-5)
On Sun, 17 Dec 1995, Ian Murdock wrote: On Sat, 16 Dec 1995, Robert Leslie wrote: I wouldn't have noticed these except I found the new xterm didn't log anything into utmp; should this really be the default? It should log to both utmp *and* wtmp by default. Could this be changed? Logging into wtmp is controlled by the loginShell resource (-ls command line option), which also controls whether the shell that is started is a login shell. I think that this should be false by default, and that the xterm started in the Xsession script should have this flag explicitly set to true. This prevents huge numbers of entries being made in wtmp for each X session, and stops /etc/profile from being run for every xterm that is started. Users who want a particular environment for processes in their X session should set it in their .xsession file. Administrators who want to set global environments should do so in a script called from the default Xsession file. Steve Early [EMAIL PROTECTED]
xsnow-1.40-0 (new package)
-BEGIN PGP SIGNED MESSAGE- xsnow (1.40-0); priority=LOW Package: xsnow Version: 1.40 Package_Revision: 0 Maintainer: Stephen Early [EMAIL PROTECTED] Description: Snow in your X server xsnow brings Christmas to your X server. A nice waste of CPU time... c74e59f4680e26b2eb6fc321b0f33860 xsnow-1.40-0.deb 2e34499c74685623b6881361d527cf72 xsnow-1.40-0.diff.gz a42b72cd66f45b5a58e5200a42edac9f xsnow-1.40-0.tar.gz - -rw-r--r-- 1 root root13997 Dec 18 00:37 xsnow-1.40-0.deb - -rw-rw-r-- 1 sde1000 sde1000 4506 Dec 18 00:37 xsnow-1.40-0.diff.gz - -rw-rw-r-- 1 sde1000 sde1000 35839 Dec 18 00:37 xsnow-1.40-0.tar.gz -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMNTABoli3Xs+7S0lAQFvVAQAwVh769Ax3RgtUkqeVTCIHxNWX+D4ZOno sPE+5b1IZpAwuVKkw7pFPtmCUaSR71eGzkqlXygvdmzCrZTR1JJfCOi1K2ZFZXsl PfEr5Ze8zTdGP7wJFE1bweXy49+JA0Dj0qXfjGwOIHKKDRCgFduhIdYS2X/iBPlo Kyezg8FXmqo= =sSTS -END PGP SIGNATURE-
xpilot-3.4.2-1
-BEGIN PGP SIGNED MESSAGE- xpilot (3.4.2-1); priority=LOW Package: xpilot Version: 3.4.2 Package_Revision: 1 Maintainer: Stephen Early [EMAIL PROTECTED] Description: Multi-player tactical game XPilot is a multi-player tactical manoeuvering game for X and Unix workstations. Players have a fighter which they move along in an artificial world and shoot each other using various kinds of weapons like bullets, mines, smart missiles, heat seekers and so on. It is a fast paced game with a lot of tactics. There are also robots flying around shooting players and other robots. Players can pick up special bonuses to improve the possibilities of their ship like more engine power or special weapons. The aim of the game is to score points and to have a lot of fun. Changes: * compiled as ELF 0e831bfcc788ab8cbc554b7bb54a8f09 xpilot-3.4.2-1.deb 94510ba0a7e091012ac6c4f78e1c7843 xpilot-3.4.2-1.diff.gz 97daa8e6a92bfab6f20dd383459afe68 xpilot-3.4.2-1.tar.gz - -rw-r--r-- 1 root root 329580 Dec 15 17:38 xpilot-3.4.2-1.deb - -rw-rw-r-- 1 sde1000 sde1000 24508 Dec 15 17:39 xpilot-3.4.2-1.diff.gz - -rw-rw-r-- 1 sde1000 sde1000739309 Dec 15 17:38 xpilot-3.4.2-1.tar.gz -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMNG1Soli3Xs+7S0lAQEJ3wP+MDzS175FVHFkq5Dx9kiVhTgN66bV+fjQ rMRU86UUdNis4Qlg9FLOOoOzHnRBV/DQ8ATXNRl7tnC5G3zhvMfWdbYERmkjtPNv oz2NnLCxmoOnqtDMWSd2aXzvZerjGSqzVSgTPpz5NfwJbSlpwVPQADaDmmHrNgJE dPxQW8OShXg= =SeOn -END PGP SIGNATURE-
Re: X package shared library problem
On Fri, 15 Dec 1995, David Engel wrote: Can this be considered to be a bug in ldconfig? Which part, deleting the link in the first place or not recreating it? The latter is not a bug. Ldconfig will never create the links needed by ld as long as I'm maintaining it. Deleting something that you are not responsible for creating is probably not a good idea. I'm open to suggestions on how to correct the former problem. What I'm leaning towards is to have ldconfig continue to remove dangling libfoo.so.* links but not libfoo.so links. That sounds sensible. Steve Early [EMAIL PROTECTED]
New X packages now available
I've announced them on debian-changes, and they are currently sitting in the queue on the European upload site. You should be able to get them from ftp://myrddin.chu.cam.ac.uk/pub/sde1000/debian/X11 until they arrive at ftp.debian.org Steve Early [EMAIL PROTECTED]
Bug#2021: man pages for lrzsz corrupt
Package: lrzsz Version: 0.11 myrddin:~$ man lrz man: ignoring unknown preprocessor `R' man: ignoring unknown preprocessor `v' man: ignoring unknown preprocessor `i' man: ignoring unknown preprocessor `s' man: ignoring unknown preprocessor `i' man: ignoring unknown preprocessor `o' man: ignoring unknown preprocessor `n' man: ignoring unknown preprocessor ` ' man: ignoring unknown preprocessor `L' man: ignoring unknown preprocessor `v' man: ignoring unknown preprocessor `l' man: ignoring unknown preprocessor ` ' .nr0C0.cp0.ds10.cp0.lf60 .nr0C0.cp0.ds10.nr0sfont1.ft.nr0spfont1.ftI.nr0ssize10z.nr0w285M.nr0h20.nr0d20.n r0w2+576.nr0h20?0.nr0d20-0?0.ft1.ft1.nrMK0.ds0sfont\n[.f]'\n[.f]'\n[.s]z'\n[.s ]z'.ds0rfont]].as10.nr0C0.cp0.ds10.cp0.lf60.if!r0x.nr0x0.if!0.if085M.as10.if!0. if035M.as10.ne0u-85M?0+(0u-35M?0).lf7.cp0.lf8 myrddin:~$ man lsz man: ignoring unknown preprocessor `R' man: ignoring unknown preprocessor `v' man: ignoring unknown preprocessor `i' man: ignoring unknown preprocessor `s' man: ignoring unknown preprocessor `i' man: ignoring unknown preprocessor `o' man: ignoring unknown preprocessor `n' man: ignoring unknown preprocessor ` ' man: ignoring unknown preprocessor `L' man: ignoring unknown preprocessor `v' man: ignoring unknown preprocessor `l' man: ignoring unknown preprocessor ` ' Reformatting lsz(1), please wait... .nr0C0.cp0.ds10.cp0.lf60 .nr0C0.cp0.ds10.nr0sfont1.ft.nr0spfont1.ftI.nr0ssize10z.nr0w285M.nr0h20.nr0d20.n r0w2+576.nr0h20?0.nr0d20-0?0.ft1.ft1.nrMK0.ds0sfont\n[.f]'\n[.f]'\n[.s]z'\n[.s ]z'.ds0rfont]].as10.nr0C0.cp0.ds10.cp0.lf60.if!r0x.nr0x0.if!0.if085M.as10.if!0. if035M.as10.ne0u-85M?0+(0u-35M?0).lf7.cp0.lf8 All of the other man pages appear to work correctly. Steve Early [EMAIL PROTECTED]
Bug#2006: elf xlib for tk40.
On Mon, 11 Dec 1995, David H. Silber wrote: Package: tk40 Version: 4.0p3-1 This requires elf-x11r6lib, which does not exist. I installed xlib-3.1.2-2, which does not seem to provide what I need, but is the latest xlib available. I then forced the install of tk40 and found out that I am still missing the elf xlib, or something. Upgrading to tk40 is my whole reason for switching to elf at this time, so this is kind of disappointing. elf-x11r6lib should be in project/experimental/elf. It's an interim package, and should hopefully be superceded later this week when I release the ELF X packages. Steve Early [EMAIL PROTECTED]
Bug#1986: stdio broken? Strange behaviour of fgets() and scanf()
On Thu, 7 Dec 1995, brian (b.c.) white wrote:
for (ksnum=0; 1; c=fgets(buf,sizeof(buf),stdin)) {
The third thing in the for structure only gets executed at end of
the loop. 'c' thus has an undefined value on the first iteration
which just happened to be NULL for you (hence the (nil) output).
GCC should have warned about this if you use -Wall.
Whoops. Yes, that much is just me being an idiot. The bit about return
values from scanf still stands, though.
Personally, I don't trust 'scanf' like this. It always seems to get
confused regarding end-of-line and so never scans where I want it to.
I always use 'fgets' followed by 'sscanf'. This, however, is not the
basis of your problem. Why you never get '-1' returned, I don't know.
The fgets() in the 'for' line seems to be to flush the remaining few
characters of the line before using scanf on the next line. Not quite how
I would have written it, but it's always worked up until this version of
libc.
Steve Early
[EMAIL PROTECTED]
Bug#1986: stdio broken? Strange behaviour of fgets() and scanf()
Maybe that's it. Maybe 'fgets' is interfering with how scanf works. Does it still fail if you remove the 'fgets' from the for loop? Yes, it still fails. I tried removing the #define from the start of the string to be matched, though, and it no longer fails. OTOH, the original program (which is too long to reproduce here) which reads a file largely consisting of #define SYMBOL VALUE lines also fails, reading to the end of the file and then carrying on reading nothing. Steve Early [EMAIL PROTECTED]
GCC/binutils shared library search changes?
Was either GCC or binutils (whichever is appropriate) changed between gcc-2.7.0-2 and gcc-2.7.2-1 or binutils-2.5.2l.20-2 and binutils-2.6-1 so that it won't find ELF shared libraries with names like libX11.so.6.0, only libraries with names like libX11.so? I ask because X has suddenly started statically linking the core binaries when I do a complete build. It compiles the shared libraries first, and puts symbolic links in a temorary 'usrlib' directory. This directory looks like this: total 0 lrwxrwxrwx 1 sde1000 sde100017 Dec 7 18:50 libFS.a - ../lib/FS/libFS.a lrwxrwxrwx 1 sde1000 sde100019 Dec 7 18:28 libICE.a - ../lib/ICE/libICE.a lrwxrwxrwx 1 sde1000 sde100024 Dec 7 18:28 libICE.so.6.0 - ../lib/ICE/libICE.so.6.0 lrwxrwxrwx 1 sde1000 sde100021 Dec 7 18:57 libPEX5.a - ../lib/PEX5/libPEX5.a lrwxrwxrwx 1 sde1000 sde100026 Dec 7 18:57 libPEX5.so.6.0 - ../lib/PEX5/libPEX5.so.6.0 lrwxrwxrwx 1 sde1000 sde100017 Dec 7 18:28 libSM.a - ../lib/SM/libSM.a lrwxrwxrwx 1 sde1000 sde100022 Dec 7 18:28 libSM.so.6.0 - ../lib/SM/libSM.so.6.0 lrwxrwxrwx 1 sde1000 sde100019 Dec 7 18:26 libX11.a - ../lib/X11/libX11.a lrwxrwxrwx 1 sde1000 sde100024 Dec 7 18:26 libX11.so.6.0 - ../lib/X11/libX11.so.6.0 etc. If this is going to be a permanent change then I can probably hack the Imakefiles to make extra lib*.so symlinks. Steve Early [EMAIL PROTECTED]
Bug#1986: stdio broken? Strange behaviour of fgets() and scanf()
Package: libc5
Version: 5.2.16-1
(My libc5-dev version is also 5.2.16-1)
The following program (which is similar in structure to one of the
programs used in building xlib) loops forever when it reaches EOF on stdin:
#include stdio.h
int main(int argc, char **argv)
{
int ksnum,i;
char buf[1024];
long val;
char *c;
printf(EOF is %d\n,EOF);
for (ksnum=0; 1; c=fgets(buf,sizeof(buf),stdin)) {
printf(c is %p\n,c);
i=scanf(#define XK_%s 0x%lx, buf, val);
printf(i is %d\n,i);
if (i==EOF)
break;
}
printf(Finished.\n);
}
Sample output (running it on its own source code):
myrddin:~/compsci/c$ ./testeof testeof.c
EOF is -1
c is (nil)
i is 0
c is 0xb5c4
i is 0
c is 0xb5c4
i is 0
[...]
c is 0xb5c4
i is 0
c is 0xb5c4
i is 0
c is (nil)
i is 0
[the next two lines...]
c is (nil)
i is 0
[...are repeated forever]
Two things are strange: the first call to fgets() returns nil, and calls
to scanf() once end-of-file has been reached return 0 rather than EOF (-1).
This worked under libc5-5.2.9-2. I noticed because it made my X build
hang; this had never happened before.
The man page for scanf says:
RETURN VALUES
These functions return the number of input items assigned,
which can be fewer than provided for, or even zero, in the
event of a matching failure. Zero indicates that, while
there was input available, no conversions were assigned;
typically this is due to an invalid input character, such
as an alphabetic character for a `%d' conversion. The
value EOF is returned if an input failure occurs before
any conversion such as an end-of-file occurs. If an error
or end-of-file occurs after conversion has begun, the num-
ber of conversions which were successfully completed is
returned.
The man page for fgets() says:
gets() and fgets() return s on success, and NULL on end of
file or error.
Steve Early
[EMAIL PROTECTED]
Bug#1925: rusers causes segmentation fault
Package: netstd Version: 1.22-1 myrddin:~$ rusers garfield.chu.cam.ac. gdm1000 gdm1000 gdm1000 turing.chu.cam.ac.uk djs1012 Segmentation fault $ rusers garfield.chu.cam.ac. gdm1000 gdm1000 gdm1000 turing.chu.cam.ac.uk djs1012 tickle.chu.cam.ac.uk apw24 myrddin.chu.cam.ac.u sde1000 gdm1000 pw201 orac.chu.cam.ac.uk rjw1004 womble.chu.cam.ac.uk scb1004 scb1004 scb1004 scb1004 piranha.chu.cam.ac.u jkr1003 jkr1003 jkr1003 jkr1003 jkr1003 Segmentation fault (Output from rusers on myrddin.chu.cam.ac.uk and chiark.chu.cam.ac.uk, two systems running Debian.) This seems to be quite an old bug; I had the same problem when I had a Slackware system. Steve Early [EMAIL PROTECTED]
Re: Missing X references
On Tue, 28 Nov 1995, Andrew Howell wrote: brian writes: I've just moved over to the new elf compiler, but am having a problem compiling a program which uses -lX11. For some reason, none of the symbols are resolved. Here is the output... [...] Was there a change to the X libs that I missed? I compiled and ran fine with the old a.out compiler. Once I solve this, I can release wine to Debian. I'm assuming that we need an ELF version of the X11R6 packages before we can compile ELF X programs. I haven't been able to compile any of my X packages for the same reason. I'm building new X packages at the moment. Although my development versions are a.out, the version that I will release will be ELF. Hopefully this will be before the new year. This release of the X packages will be a bit different from previous releases, in that it's being built from the XFree86-3.1.2S source rather than from binaries. Steve Early [EMAIL PROTECTED]
Re: Missing X references
On Tue, 28 Nov 1995, David Engel wrote: I've just moved over to the new elf compiler, but am having a problem compiling a program which uses -lX11. For some reason, none of the symbols are resolved. Here is the output... You'll need to use the interim elf-x11r6lib package and explicitly link with -L /usr/i486-linuxelf/lib until the X packages are converted to ELF. I can't find this package. Am I supposed to be responsible for it? The new X packages that I hope to release before Christmas will be ELF, compiled from the XFree86-3.1.2S sources rather than from the binaries distributed by XFree86. Steve Early [EMAIL PROTECTED]
