Re: beware sysvinit 2.58 installation
'Miquel van Smoorenburg wrote:' I've changed the postinst script to create a symbolic link in /var/log, so that it will (hopefully) work in all cases. It is also backwards compatible with other programs (UPS watchdogs etc) this way. If I don't get any replies saying this is a bad idea I'll upload the new version this afternoon (MET). You might consider putting the symbolic link in the main installation rather than the postinst (I may be wrong but having dpkg manage the file seems easier administratively). And I think relative symbolic links are to be preferred too. But no objection (from me :) in any case. -- Christopher J. Fearnley|UNIX SIG Leader at PACS [EMAIL PROTECTED] (finger me!)|(Philadelphia Area Computer Society) http://www.netaxs.com/~cjf |Design Science Revolutionary ftp://ftp.netaxs.com/people/cjf|Explorer in Universe Dare to be Naive -- Bucky Fuller |Linux Advocate
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-
Debian ALPHA-TEST Acct/Pass
Have the account name or password changed for ftp.debian.org? My mirror is no longer fetching the development tree. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#2091: creating packages requires root privileges
Package: dpkg To create a binary *.deb package, root privileges are required. This is because you must create a complete directory structure with proper ownerships and permissions first, and then use dpkg-deb to create a package from it. But this should't really be necessary. A tar file is a tar file, and you can set any permissions inside it if you can write to it. The only thing that is necessary is a program to set permissions inside tar files. This looks more like a suggestion than a bug report to me... If you're creating a Debian package you need to be root on the system you're going to install it on to test it. Even if you're using some shared environment in which you don't have root on the main development machine, is it really that problematic to make the `binary' target on the test machine? However, I haven't tried to build Debian packages in that sort of environment, so there may be gotchas I'm missing. A tool which could adjust permissions and ownership of the contents of a tar file shouldn't be hard to write; you'd still have to get the tar file back into the deb archive, of course. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#2073: assembler problems in asm/io.h during build of kernel
I saw this on comp.os.linux.development.system, but I haven't tried if it still compiles the kernel with gcc 2.7.x... From: Russell Johnston [EMAIL PROTECTED] Newsgroups: comp.os.linux.development.system Subject: Re: gcc 2.7.2 and kernel 1.2.13 This patch allows compilation of kernel 1.2.13 with gcc 2.7.0 Russell Johnston [EMAIL PROTECTED] --- ./linux/include/asm-i386/io.h- Mon Aug 15 00:56:19 1994 +++ ./linux/include/asm-i386/io.h Wed Nov 15 23:04:25 1995 Well, there is evidently more to it than that since there are all sorts of missing symbols when you go to link. BTW, I made a simple addition to the patch so that it will compile under elf or aout by testing for the define __ELF__. I'll look around a bit more for where these functions might be hiding. Thanks for your help. Darren [EMAIL PROTECTED] http://www.daft.com/~torin/[EMAIL PROTECTED] [EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Do you have your clothes on? I probably don't. Take yours off. Feel better. @ @ Sysadmin, webweaver, postmaster for hire. C and Perl programmer and tutor. @
Bug#2091: creating packages requires root privileges
If you're creating a Debian package you need to be root on the system you're going to install it on to test it. Even if you're using some shared environment in which you don't have root on the main development machine, is it really that problematic to make the `binary' target on the test machine? It isn't _that_ problematic, but it is inconvenient, and technically not necessary. It isn't that problematic to transfer a few files using FTP, but it is often a lot more convenient to use NFS :-). Besides, it is generally recommended to do most things as an ordinary user, and use root only if really necessary. A tool which could adjust permissions and ownership of the contents of a tar file shouldn't be hard to write; you'd still have to get the tar file back into the deb archive, of course. Or modify dpkg-deb to read a file (part of the source package) which specifies permissions of all files, and modify the intermediate tar archive while creating the package. I'm not sure about dpkg internals... Even if there is no intermediate tar file (output from tar is piped to gzip), it should still be possible to write a filter that reads a tar archive from stdin, changes the permissions to these specifed in the permissions file, and writes the modified tar archive to stdout (pipe to gzip in this case). Tar files are, by their nature (tape archive), sequential - no random read/write access should be required to do this. The package-specific permissions file could also be installed somewhere in /var/lib/dpkg/... and later used to verify that the permissions are correct, and fix them without reinstalling if they ever get messed up. Probably the biggest problem: find someone to write the program to change permissions inside tar files. Any tar file format experts out there? Marek
Re: ncurses-1.9.8a ELF release
David Engel writes (Re: ncurses-1.9.8a ELF release): Slowly. I've been trying to better understand how dpkg works and find a way to do what I want with the current behaviour. The only way I've come up with is rather ugly and probably error prone so I haven't even bother to hash it all out. If you'll answer me a couple of questions, I'll try to come up with a cleaner way that would only require a minimum of changes to dpkg. Here they are: Can, and if so how, dpkg/dselect remove one package and replace it with another in one invocation? Yes. There are some restrictions - most importantly, that the package being replaced be deselected first, or that both the new and old packages be marked essential. Usually dselect and the Conflicts mechanism will handle that bit. You can replace only one package at a time, but an upgrade can replace one other package as well as the previous version of the package being installed. Does dpkg/dselect allow a package to be upgraded or replced with another and then left in an unconfigured state? Yes, it does. This is necessary to avoid having ordering restrictions on the bulk transfer part of the installation. Basically, what I'm concerned with is the time between an old package's postrm script being called and any new package's postinst being called. I think you need to read project/standards/maintainer-script-args.txt - it describes in some detail exactly what happens when and which scripts get called. Ian.
Useless use of -lfoo (fwd)
After Ian Lance Taylor from cygnus has confirmed that GNU ld for ELF will continue to behave that way, I'd like to pass this to the maintainer of debian packages. The latest packages I've compiled and seen some superfluous -lfoo are: man-2.3.10-6: manpath (-lgdbm) zsoelim (-lgdbm) git-4.3.7-5: gitview (-lreadline) gitcmp (-lreadline -lncurses) gitkeys (-lreadline -lncurses) gitmatch(-lreadline -lncurses) gitwipe (-lreadline -lncurses) perl-5.002-3: a2p (-lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lbsd) mfg Rolf Rossius -- Forwarded message -- Date: Tue, 19 Dec 1995 03:53:35 +0100 (MET) From: roro [EMAIL PROTECTED] To: David Engel [EMAIL PROTECTED] Subject: Useless use of -lfoo A peculiarity of the link editor for ELF (in contrast to aout) will not harm, but sometimes do unwanted things for the resulting binary. I have noticed this in the package git and suspect there are others. The configuration and build process for a packages often collects the names of the needed libraries and add -lfoo -lbar -lbaz to the link flags for *all* binaries. Even if no functions or objects from libbar (a shared lib) are required for a binary, the soname of libbar libbar.so.x is noted in the bin and this file is necessary at runtime. ELF: [EMAIL PROTECTED]:tty6:~/tmp$ gcc t.c [EMAIL PROTECTED]:tty6:~/tmp$ ldd a.out libc.so.5 = /lib/libc.so.5.2.18 [EMAIL PROTECTED]:tty6:~/tmp$ gcc t.c -lm [EMAIL PROTECTED]:tty6:~/tmp$ ldd a.out libm.so.5 = /lib/libm.so.5.0.5 libc.so.5 = /lib/libc.so.5.2.18 For the aout format, an additional -lm makes no difference (assuming libm is not needed by t.c): [EMAIL PROTECTED]:tty6:~/tmp$ gcc -b i486-linuxaout t.c [EMAIL PROTECTED]:tty6:~/tmp$ ldd a.out libc.so.4 (DLL Jump 4.7pl5) = /lib/libc.so.4.7.5 [EMAIL PROTECTED]:tty6:~/tmp$ gcc -b i486-linuxaout t.c -lm [EMAIL PROTECTED]:tty6:~/tmp$ ldd a.out libc.so.4 (DLL Jump 4.7pl5) = /lib/libc.so.4.7.5 I don't know whether it is *that* important. But should the debian package maintainer not be better aware of this fact, be encouraged to adjust the link flags and maybe report to upstream maintainer? What do you think? mfg Rolf Rossius
Re: beware sysvinit 2.58 installation
The 0.93R6 sysvinit-2.57b used /var/log/initrunlevel as the file to
communicate with init. The debian-1.0 version of sysvinit-2.57b
Interesting. I was just about to submit a report about how if I did a
shutdown -h now, it halted the system, and then if I hit ctl-alt-del I
got a message about unable to write to /var/log/initrunlevel. It
turns out that I don't *have* a /var/log/initrunlevel, even in normal
operation... it appears that the sysvinit-2.57b package doesn't
create it, and init itself doesn't either.
So I tried to figure out where telinit was actually writing... and
found a bug in strace -- note the open, and then the write; the args
to open are pretty clearly wrong (since not only doesn't that file
exist, the directory doesn't...)
stat(/usr/lib/locale/libc/C/usr/share/locale/C/libc.cat, 0xb46c) = -1
ENOENT (No such file or directory)
stat(/usr/local/share/locale/C/libc.cat, 0xb46c) = -1 ENOENT (No such
file or directory)
geteuid() = 0
umask(022) = 022
brk(0xb000) = 0xb000
open(/usr/local/share/locale/C/libc.cat, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
brk(0xc000) = 0xc000
write(3, 2 20, 4) = 4
close(3)= 0
INIT: Switching to runlevel: 2
) = 0
_exit(0)= ?
curiouser and curiouser...
Bug#2092: procps needs an update for kernels 1.3.53
Package: procps Kernel 1.3.53 seems to have changed the way memory use is reported (I think it reports a new value in /proc/meminfo, cached:, referring to cached VM pages) and also has an internal process kernel bdflush that has a space in its name. The result is that top and ps can dump core with floating exceptions (divide by 0, I think) or bus errors. Patches for ps are floating around on the kernel mailing list. 1.3.53 is significantly faster than previous kernels because of page cacheing. Thanks Bruce -- Bruce Perens [EMAIL PROTECTED] Pixar Animation Studios Toy Story: US$152M domestic box office receipts so far.
Bug summaries by maintainer
These listings have been using out-of-date overrides file and Packages file information, because the cron job to update my local copy wasn't working. I think I've fixed that now, and the next summary should be correct. Please let me know of any further problems. Thanks, Ian. (BTW: I've just caught up with my personal mail here; I still have about 100 debian-devel messages marked to save or reply to, which I won't get around to today. Please bear with me ...)
Bug#2093: perl dumps core on libwww-perl-5b5
Package: perl
Version: 5.002-3
Perl dumps core when run on the VERSION file included with
libwww-perl-5b5 (Avaiable via the CPAN archive). A copy of the
VERSION file is included.
#!/bin/perl
=head1 VERSION
This is a self-modifying file. Whenever a version number in one of the
members increases, this program increases its own version number by
0.01. Can also increment alfa/beta version numbers. Members are
enumerated below the __END__ token.
This implies that we get a new timestamp. If we make Makefile
dependent on this program, we get a new Makefile everytime one of the
versions changes. It is really not the cheapest solution, but maybe
the most trivial one.
Add a new module by writing its name on a line after the __END__ token.
Change the overall version number arbitrarily by changing it within
this file.
=head1 Author
Andreas Koenig [EMAIL PROTECTED]
=cut
$VERSION=5b5;
use lib lib;
while (DATA){
chop;
my($lib,$version)=split;
next unless $lib;
$lib{$lib}=$version || 0;
}
for $lib (sort keys %lib) {
push @m, use $lib;;
push @n, \$rewrite++ if \$$lib\::VERSION $lib{$lib};\n;
push @o, $lib \$$lib\::VERSION\n;
}
eval join , @m;
die $@ if $@;
eval join , @n;
die $@ if $@;
eval join , \$o = \, @o, \;
die $@ if $@;
rewrite if $rewrite;
print $VERSION\n;
sub rewrite
{
# Increment version number
if ($VERSION =~ /((?:^\d+(?:\.\d+)?-?)?[ab])(\d+)$/) {
$VERSION = $1 . ($2 + 1);
} else {
$VERSION = sprintf(%.2f, $VERSION + 0.01);
}
# Patch this file
open READ, $0 or die Can't read myself: $!;
$versions = ;
while (READ) {
s/(^\$VERSION=)\d+(?:\.\d+)?;/$1$VERSION;/;
s/(^\$VERSION=)\S+/$1$VERSION/;
$versions .= $_;
last if /^__END__/;
}
close READ;
open WRITE, $0;
print WRITE $versions;
print WRITE $o;
close WRITE;
}
__END__
Font::AFM 1.07
HTML::Element 1.18
HTML::Entities 1.01
HTML::Parse 1.11
HTTP::Date 1.10
LWP 0.05
LWP::Socket 1.15
MIME::Base64 1.03
MIME::QuotedPrint 1.04
Mail::Cap 1.03
URI::URL 3.05
Re: Bug#2092: procps needs an update for kernels 1.3.53
Note that current 1.3.x kernels seem to have everything in /proc/ksyms, instead of just one page. Using that information, psupdate and System.map are completely unnecessary. Jeff
Updated expect package
Date: 04 Jan 96 19:30 UT Source: expect Binary: expect Version: 5.18.1-2 Description: expect: The expect/expectk programs and libraries. Priority: Low Changes: Fixed Bug#1836: expect core dumps. Files: -rw-rw-r-- 1 root src392703 Jan 4 13:29 expect-5.18.1-2.tar.gz -rw-rw-r-- 1 root src 3303 Jan 4 13:30 expect-5.18.1-2.diff.gz -rw-r--r-- 1 root root 367288 Jan 4 13:29 expect-5.18.1-2.deb 7f45ff721b37d1d2e305f0435025e752 expect-5.18.1-2.tar.gz 8f6acf563dc3b0c751259cd2bab2a5a3 expect-5.18.1-2.diff.gz 80697b1d1db5b10337513c3da26a8fbd expect-5.18.1-2.deb -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
New ical package
Christian Linhart hasn't updated ical in a while so I took the liberty of doing so. Date: 05 Jan 96 04:10 UT Source: ical Binary: ical Version: 2.0p2-1 Description: ical: An X11/Tk Calendar application Priority: Low Changes: Updated to new upstream version. . Converted to ELF. Files: -rw-rw-r-- 1 root src268525 Jan 4 22:10 ical-2.0p2-1.tar.gz -rw-rw-r-- 1 root src 2095 Jan 4 22:10 ical-2.0p2-1.diff.gz -rw-r--r-- 1 root root 155089 Jan 4 22:10 ical-2.0p2-1.deb 6a6f73f44bc33e4523c0a64f449d6d6d ical-2.0p2-1.tar.gz a9b11c18afabb925c264756bc0e1cd48 ical-2.0p2-1.diff.gz ea85fe25fa4a23735275edef8268a049 ical-2.0p2-1.deb -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
