Re: binary-alpha and binary-sparc directories
Bill Mitchell writes (Re: binary-alpha and binary-sparc directories): This seems shakey -- especially if we posit that the i386 maintainer is in the U.S., the Mac maintainer in Germany, and the PowerPC maintainer in Korea. Also, the upstream source maintainer might be in Romania, and might not be be interested in picking up the Mac and PowerPC changes which our maintainers have made to his source code. The (primary) maintainer of a package is the one who maintains the *source*. They may not necessarily build the i386 binary, perhaps only the m68k or some such. A Debian source package should compile under any architecture (unless its function is inherently architecture-specific). If it doesn't it is a bug which it is the responsibility of the primary maintainer to fix. If the primary maintainer doesn't fix it we should consider the package orphaned, and then the person trying to build for another architecture can upload their source as the generic source, either officially taking over the package or just putting out an `interim' release. There's no problem, btw, with having several source versions in the FTP site. We should only delete an old source version when all the old binaries have been replaced with the new ones (this is a GPL requirement, amongst other things). Ian.
Files on the FTP site...
ncurses3.0-1.9.8a-3 should be in base, seeing as how it contains the shared libraries. Also, strictly speaking, ncurses-bin-1.9.8a-3 probably doesn't _need_ to be in base (I'd hope the programs in it probably aren't going to see much use). Also, the latest versions of minicom/lrzsz seem to have disappeared from Incoming, yet they are not in either the stable or ALPHA trees. I'm going to re-upload them on the assumption that this was accidental. If they could be placed in both the stable and ALPHA trees, I'd appreciate it---maybe we'd finally quit getting bug reports on lrzsz-0.11. Mike. -- I thought I'd something more to say.
Re: ftp method v2
Andy Guy writes (ftp method v2): eg, if: Filename: development/binary/text/a2gs-1.0-4.deb looks for a2gs-1.0-4.deb in the ls -lR listing (it will probably find it in text/ !). If it cannot find a Filename field it falls back on using pkgname-ver[-rev].deb. That's an improvement, but still not foolproof. Can you get it to download just the start of the file and then abort the transfer ? WHAT TO DO: To install, untar the attached file and copy into /usr/lib/dpkg/methods/ftp Can you recommend people put this in /usr/local/lib/dpkg/methods, please ? That way if anything breaks it will be obvious what is part of the dpkg package proper and what is locally installed. Compile the dvercmp.c file, and put the executable some where in the default path (/usr/local/bin) Create a directory /var/lib/dpkg/methods/ftp You could supply a tarfile that contains /usr/local/lib/dpkg/methods/ftp/... /var/lib/dpkg/methods/ftp/ [empty directory] /usr/local/bin/dvercmp perhaps. Install: [ description ] Does this mean that you have to have enough spare disk space to contain all the files you're installing ? WARNING: [...] To interface to ftp program it creates a .netrc file (there is no way to use an alternate .netrc file from ftp -- arrggghhh), it tries to keep your current .netrc intact and not leave a .netrc lying around at the end - but it may. Why not do without a netrc and use `ftp -n' and `user anonymous email' ? I havn't changed the default .deb filename to include two hyphens, it is a trival change but not really necessary now I use the Filename: field. That's fine, thanks. Ian.
Bug#2102: ediff.info missing from emacs
Package: emacs Version: 19.29-4 `M-x ediff-documentation' tells me that ediff.info is missing (it is) and that it is part of the Emacs distribution (I haven't confirmed). In any case, I think it ought to be part of emacs.deb.
Bug#2100: Efax: errors in /usr/bin/fax
b c writes: Brian Package: efax Brian Version: 07a Brian Revision: 4 Brian Brian 1) The security hole still exists because the C0 command is still Brian present when going into answer mode on systems that will accept Brian incoming data connections. The string C1 should be added to the Brian DATAINIT variable on such systems. I have heard that some modems Brian will not receive faxes under this setup, however. Yes, you reported that once before as bug#1949. The author of efax is aware of this, but has no answer (yet). A new version of efax is due RSN anyway. All I can do at this stage is to but a warning into /etc/efax.rc just before the DATAINIT declaration. I doubt that many people use efax for fax and data calls. Brian 2) The 'sed' line that processes the device name into a log-file Brian name needs a small fix in case (for some oddball reason) the device Brian name has more than one slash in it. (line 394) Brian Brian From: eval DEVN=`echo $DEV|sed -e s./._.` Brian To: eval DEVN=`echo$ DEV|sed -e s./._.g` Wait a sec. A common definition of DEV is cua1 or cua3. There is not even _one_ slash, let alone two. I don't see the the merit of this patch. Brian 3) An incorrect directory is specified for answer mode. (line 427) Brian Brian From: if cd $FAXDIR ; then : Brian To: if cd $FAXINDIR ; then : That is indeed a bug, caused by the qfax patch that I integrated on demand. I'll fix this one and report it upstream to the qfax author. I close this bug report, given that 1) is still open as bug#1949. -- Dirk Eddelbuttel http://qed.econ.queensu.ca/~edd
binary-i386
Could binary-i386 be added as a symbolic link until the files are actually moved. I'd like the version of dftp I'm about to release to handle an architecture setting. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
cfengine-1.2.14-3
Date: 07 Jan 96 18:07 UT Source: cfengine Binary: cfengine Version: 1.2.14-3 Description: cfengine: A tool for configuring and maintaining operating systems Priority: Low Changes: * rebuilt for elf Files: -rw-r--r-- 1 root staff 237483 Jan 7 10:07 cfengine-1.2.14-3.tar.gz -rw-r--r-- 1 root staff7446 Jan 7 10:07 cfengine-1.2.14-3.diff.gz -rw-r--r-- 1 root root 226905 Jan 7 10:06 cfengine-1.2.14-3.deb aa0aafc4c5be05e15ea2df1652ff6c00 cfengine-1.2.14-3.tar.gz c5afdf2f3d1f58cace8e101bb9d39b11 cfengine-1.2.14-3.diff.gz 72325e6123de1f91059c2823ea677df6 cfengine-1.2.14-3.deb
Bug#2059: dpkg and depend on versions
Erick Branderhorst writes (Re: Bug#2059: dpkg and depend on versions): Yes, I'm sure, the transcription was in chronological order. I didn't understand the `5' either. Chronological order ? I was thinking that perhaps the was causing it? Is the conflicting version number calculated from (2.3.10-6) or is it displayed right away after reading it from the status file. I should have send the status file probably but I think it is too late now. The conflicting version number isn't *calculated* at all, it just comes out of dpkg's idea of what's in the status file ... If you can't reproduce this I suppose I'll have to close the report. Ian.
Bug#2103: diald often must use ttyS? rather than cua?
Package: diald Version: 0.10-2 The following situation seems to plague many Debian users who want to use diald. Christian Lynbech wrote: I have it working now. I [...] changed the device from /dev/cua1 to /dev/ttyS1 and diald finally started to work. I think there must be something about the debian distribution that creates the requirement to use /dev/ttyS? instead of /dev/cua?, even though this is not necessary when using pppd directly. I don't know why, but we should find out how we can fix the problem (long-term) and/or document it in the /usr/doc/diald documents (short-term). Maybe something in /dev needs to be changed? Sorry, I don't know much about this kind of thing. [root]:/dev# ll /dev/cua0 crw-rw 1 root dialout5, 64 Jan 6 13:25 /dev/cua0 [root]:/dev# ll /dev/ttyS0 crw-rw-rw- 1 root tty4, 64 Jan 6 15:08 /dev/ttyS0 -- Jeff Ebert [EMAIL PROTECTED] ho-hum
Thoughts on Replaces field (was Re: binary-alpha and binary-sparc directories)
'Ian Jackson wrote:' I think I'll have to support `Replaces' or something, so that old packages can have all their files `taken away' and disappear eventually. Here's the scenario that I hope a Replaces fiels might resolve. I'm working on the S-lang library. Both most and Midnight Commander depend on S-lang, so building a shared library makes sense (and with ELF it's easy to do!). But S-lang is under development and shared libraries aren't compatible from month-to-month (unless I don't understand some subtlety in ELF - very likely, actually). I released most-4.5.0-1 and slang-lib-0.99.23-1. But now I want to release slang-lib-0.99.24-1, but it's incompatible with slang-lib-0.99.23-1 which it should replace. Of course, most depends on slang-lib (version 0.99.23-1 ONLY). most-4.5.0-1 breaks with slang-lib-0.99.24-1. So I need to build another most with slang-lib-0.99.24-1 support. So I envision this specification for the Replaces: field: GIVEN: A, B, and C all depend on package D AND Package E replaces package D. Then When E is installed, it leaves D alone (since things still depend on D). When A, B, or C are upgraded (to versions compatible with E) they are removed from D's dependancy list. Once D's dependency list is empty, D is removed (making sure that E is intact). I think this would give the flexiblity that the S-lang example needs and that isn't presently present. If I remember correctly Ian didn't like encoding the shared library version in the package name (I'm starting to agree). But right now that is the only proposed solution to the problem that I've seen. OK, now I'm waiting for you all to tell me what details I've omitted ... BTW, I think dpkg blazes - performance-wise (especially compared to rpm which is a dog)! Well done. -- 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
Re: binary-alpha and binary-sparc directories
Raul Miller writes (Re: binary-alpha and binary-sparc directories): How about the option of a better record of what has happened? For example, currently, if multiple packages supply the same file only the most recently installed package has the files listed in it's .list file. If we have package installation time recorded, we wouldn't lose any information if (a) all packages which supplied a file had the file listed in their .list files. (b) the default behavior of dpkg would be to not remove a file till all packages with references to it were removed. This makes sense. I think I'll have to support `Replaces' or something, so that old packages can have all their files `taken away' and disappear eventually. If it's a speed issue, perhaps I should spend some time profiling dpkg? No, it's not a speed issue - it's a question of deciding what the behaviour should be and then me finding time to implement it. I've added this to the wishlist ... Ian.
Bug#2060: dpkg and depends on version again
Erick Branderhorst writes (Re: Bug#2060: dpkg and depends on version again): How about = = for less/greater than or equal to Ok for strictly less/greater thani Ok for less/greater than or equal to (backwards compatibility, generates warning from dpkg-deb) Ok but an fatal error from dpkg-deb would be better than just a warning. = for equal to You're right, of course. Pleasing symmetry is often appropriate, but not here I think. = = less/greater or equal strictly less/greater less/greater or equal - produces warning from dpkg --build Erick Branderhorst writes (Re: Bug#2060: dpkg and depends on version again): Ok but an fatal error from dpkg-deb would be better than just a warning. Bill Mitchell writes (Re: Bug#2060: dpkg and depends on version again): How about no warning on package config/install operations, and a fatal error on package-build operations? No, because that breaks existing source packages. Ian.
Bug#2101: xserver packages fail installation in postinst
Package: xserver-svga Version: 3.1.2 Revision: 2 (and, I'd guess, other xserver packages as well) The package won't install on a 0.93r6 system without a previous X11 installation. It presumes the existence of nonexistent things, and fails in postinst when they're not found. Script started on Sat Jan 6 16:35:09 1996 root:x11# dpkg --install xlib.deb Selecting previously deselected package xlib. (Reading database ... 11252 files and directories currently installed.) Unpacking xlib (from xlib.deb) ... Setting up xlib ... root:x11# dpkg --install xsvga.deb (Reading database ... 11263 files and directories currently installed.) Preparing to replace xserver-svga (using xsvga.deb) ... Unpacking replacement xserver-svga ... Setting up xserver-svga ... Warning: /usr/X11R6/lib/X11/XF86Config is not a symlink. It is being renamed to /usr/X11R6/lib/X11/XF86Config.old mv: /usr/X11R6/lib/X11/XF86Config: No such file or directory dpkg: error processing xserver-svga (--install): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: xserver-svga root:x11# dpkg --info xsvga.deb old debian package, version 0.939000. size 1079054 bytes: control archive= 1117, main archive= 1077923. 253 bytes,12 lines control 2296 bytes,83 lines * postinst #!/bin/bash 101 bytes, 7 lines * postrm #!/bin/bash Package: xserver-svga Version: 3.1.2 Revision: 2 Section: x11 Priority: optional Maintainer: Stephen Early [EMAIL PROTECTED] Depends: libc5 Recommends: xfntbase Optional: xbase Provides: xserver Conflicts: xsvga Description: XFree86 3.1.2 SVGA server root:x11# Script done on Sat Jan 6 16:36:52 1996
Bug#2100: Efax: errors in /usr/bin/fax
b c writes: Brian (4) The /var/spool/fax is of the dialout group. Should this be Brian the fax group instead? Also, how about setting the permission of Brian this directory and those under it to drwxr-s--- so only people in Brian that group can send/view faxes. The 's' would also make sure that Brian all files created under it have the groupid of fax. There is no group fax, and I do not intend to create one. dialout seems quite appropriate to me. Let's not forgot that efax was written as sample simple fax system. Let me quote from the README file: efax is a relatively small ANSI C/POSIX program that provides the data transport function for fax applications. A simple shell script (``fax'') is included in the distribution to let you create, send, receive, view and print faxes. efax is smaller and easier to install than FlexFax, NetFax, or mgetty+sendfax. It uses your system's own getty to handle incoming data calls. As one user put it, ``EFAX is a nice simple program for single user systems.'' For super-duper multi-user coffee-brewing singing dancing fax support, you probably want to go with flexfax/hylafax or some other fax program. I packaged efax as it does what I need on my (mostly) single-user system. More complex systems are welcome. -- Dirk Eddelbuttel http://qed.econ.queensu.ca/~edd
