Re: Bug#514411: [Resolvconf-devel] Bug#514411: resolvconf breaks all network operations
Thomas Hood wrote: iface eth0 inet static address 172.17.207.12 gateway 172.17.207.1 netmask 255.255.255.0 I'll assume that interface eth0 is configured using the ifup command. Add this line to the iface eth0 stanza in /etc/network/interfaces dns-nameservers 172.17.207.1 172.17.207.18 Then do, as root: ifdown eth0 ifup eth0 Then your resolv.conf file should be correct. Please read resolvconf(8) and the README file in/usr/share/doc/resolvconf for background information. Why on earth would I want to do that? /etc/resolv.conf has been a perfectly fine way of statically configuring name servers for the last few decades. resolvconf should quite simply not modify /etc/resolv.conf if it doesn't know the right thing to put there. Then this sort of problem would never arise. As I said, I didn't even ask to install it. I don't see why I should jump through extra nonstandard hoops just because its author can't be bothered with some simple sanity checks. ttfn/rjk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
What should postrm purge actually do?
Is it written down anywhere what postrm purge is supposed to do? Presumably remove some set of files, but what criteria should be used to choose which? The policy document is not much help; s6.8 says when it is called, but not what it actually needs to do. I can't find more detail, though of course I may have missed it. Things I think it should remove: - generated configuration files Things I'm uncertain about, but that wouldn't be missed: - infrastructural stuff (lockfiles, sockets, etc) - files containing cached data Things I'm uncertain about, that someone might actually miss: - log files - data accumulated from users Configuration files might be missed too, so obviously --purge isn't intended to be nondestructive, the question is how destructive is it supposed to be and to what extent is it responsible for tidying up. ttfn/rjk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changing subjects when discussion becomes slightly off-topic - Was: Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Miriam Ruiz [EMAIL PROTECTED] writes: Maybe there should also be a clasification of packages according to how bad would a bug be in them for the whole system, so that patches in those could be more carefully reviewed. Perhaps uploads could come with the diff against the last version (or a link to it)? -- http://www.greenend.org.uk/rjk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is openssl actually safe now? (was: debian infrastructure ssh key logins disabled, passwords reset)
BALLABIO GERARDO [EMAIL PROTECTED] writes: if I understand correctly, the problem was that openssl used some segment of uninitialized memory as a source of entropy, and the offending patch cleared it. This is not correct. Clearing tmpbuf before reading /dev/urandom is harmless. The broken change can be found at these URLs: http://svn.debian.org/viewsvn/pkg-openssl?rev=141view=rev http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141r1=140r2=141 Reverting the patch obviously restored the pristine behavior. However I wonder, is the pristine behavior correct? As far as I know, it is NOT justified at all to rely on the assumption that uninitialized memory contains random data. I read that many architectures reset it to some magic number, e.g., 0xdeadbeef. Is that correct? It's harmless (it doesn't make the RNG any worse) but also pointless (the uninitialized part of the input buffer may well be predictable). If so, and if that was the ONLY entropy source used in generating keys, then upstream openssl is (and has always been) just as broken as the patched Debian package. While if it was only used in addition to other sources, all this is probably a non-issue. The uninitialized data is not the only source of entropy. ttfn/rjk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Thomas Dickey, your mail is bouncing...
Hopefuly someone helpful person on debian-devel has another means to
contact him, if he doesn't know already?
ttfn/rjk
Mail Delivery System writes:
This message was created automatically by mail delivery software (Exim).
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[EMAIL PROTECTED]
SMTP error from remote mailer after MAIL FROM:[EMAIL PROTECTED]:
host mail1.radix.net [207.192.128.31]: 550 5.0.0 Unauthorized Sender Jul
05
-- This is a copy of the message, including all the headers. --
Return-path: [EMAIL PROTECTED]
Received: from [172.17.207.1] (helo=sfere.anjou.terraraq.org.uk)
by chiark.greenend.org.uk (Debian Exim 3.35 #1) with esmtp
(return-path [EMAIL PROTECTED])
id 1FAmKD-0002xn-00; Sun, 19 Feb 2006 11:01:57 +
Received: from richard by sfere.anjou.terraraq.org.uk with local (Exim 4.50
#1 (Debian))
id 1FAmKC-0001iC-55; Sun, 19 Feb 2006 11:01:56 +
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: [EMAIL PROTECTED]
Date: Sun, 19 Feb 2006 11:01:56 +
From: Richard Kettlewell [EMAIL PROTECTED]
X-Face:
h[Hh-7npeb4/eW[]sat,I3O`t8A`(ej.H!F4\8|;ih)`7{@:A~/j1}gTt4e7-n*F?.Rl^
F\{jehn7.KrO{!7=:(@J~].[{v9!1qZY,{EJxg6?Er4Y7Ng2\FtZW?r\c.!4DXH5PWpgaha
+r0NzP?vnz:e/knOY)PI-
X-Boydie: NO
X-Mailer: Norman
To: Thomas Dickey [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Bug#283232: screen, delete keys and terminal types
In-Reply-To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
X-Mailer: VM 7.19 under Emacs 21.4.1
Thomas Dickey writes:
nsterm is the recommended $TERM for Terminal.app; report bugs
against that rather than screen (reading screen's source code should
give a hint why it's better to make the terminal description correct
than continue hacking screen).
That's useful to know. Thankyou for chiming in.
ttfn/rjk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
Gunnar Wolf [EMAIL PROTECTED] writes: Richard Kettlewell dijo [Fri, Jun 10, 2005 at 03:42:01PM +0100]: I think it doesn't go far enough. mv sbin/* bin rmdir sbin ln -s bin sbin ...and the problem goes away forever. You type too fast. Are you _sure_ no two Debian packages provide overlapping /bin/$that and /sbin/$that ? Or /usr/bin/$foo and /usr/sbin/$foo ? Or (going back some flamewars^Wweeks) /bin/$bleh and /usr/bin/$bleh ? ...Or, mix-and-match, /sbin/$this and /usr/bin/$this? There are some examples of symlinks between bin and sbin, presumably to work around the existing sbin braindamage. /sbin/ip - /bin/ip, for instance. Not hard to cope with when you make the transition and for the longer term, dpkg could probably be taught to handle this case sensibly. If there's a case where you have /bin/foo and /sbin/foo actually meaning something different then that's plainly a bug in at least one of them, if not both, and needs fixing regardless. -- http://www.greenend.org.uk/rjk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
Miles Bader [EMAIL PROTECTED] writes: astronut [EMAIL PROTECTED] writes: I agree. The type of user who is likely to be using the ifconfig command on a regular basis is the type of user who probably already has sbin in their path. (Power user, sysadmin's nonprivleged account, etc.). Yes. The great majority of users don't want to know about stuff like ifconfig, and those that _do_ can either put /sbin in their path themselves or just type the damn path when they run the command. I've no clue why some people whine so much about this. It causes (at least) two types of trivial irritation: 1) on each new system I have to add sbin to my path, usually at the point where I'm involved in the already irritating exercise of debugging a network problem 2) when helping someone out, if you ask them to report what 'ifconfig' says then the answer is: -bash: ifconfig: command not found If there was a clear benefit to having ifconfig in sbin then these might be less annoying. But I've yet to hear of one. There is a small benefit to having a separate sbin at all, in that it takes a few things out of the namespace for tab completion. Personally I don't think that outweighs the inconvenience of people wrongly putting commands like ifconfig and (historically) traceroute in it. -- http://www.greenend.org.uk/rjk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
Bernd Eckenfels [EMAIL PROTECTED] writes: The problem here is that ifconfig must be in sbin by FHS and by history (would break too many scripts). So moving is not an option. I can however put a symlink in /bin, however I am not sure how other DDs think about it, as this will set a bad precedence. I think it doesn't go far enough. mv sbin/* bin rmdir sbin ln -s bin sbin ...and the problem goes away forever. -- http://www.greenend.org.uk/rjk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
a couple of missing sources for stable
I use debmirror to maintain a local Debian archive, off ftp.uk.debian.org and www.mirror.ac.uk. I get errors regarding the following files: dists/potato/main/source/games/xdigger_1.0.10-1.diff.gz dists/potato/main/source/games/xdigger_1.0.10-1.dsc dists/potato/main/source/games/xdigger_1.0.10.orig.tar.gz dists/potato/main/source/games/xsol_0.31-3.1.diff.gz dists/potato/main/source/games/xsol_0.31-3.1.dsc dists/potato/main/source/games/xsol_0.31.orig.tar.gz I didn't ask for potato to be mirrored, but it seems that some files in stable are actually located in potato's directory. Anyway these files don't appear to exist on either the mirrors I use nor ftp.debian.org, despite being listed in stable's Sources.gz. Either stable's Sources.gz should be corrected (if the source files are in fact somewhere else), or the source files should be uploaded to the right place, or the .deb files should be removed. ttfn/rjk
Re: many scripts fail if /tmp/tempfile.$$ exists - local DOS vulnerability
Jakob Lell [EMAIL PROTECTED] writes: many shell scripts use tempfiles like /tmp/tempfile.$$. This creates insecure tempfile vulnerabilities. One commonly used fix for this problem is to use set -e or/and set -C in the shell script. This makes the whole script fail if one command fails or pipes anything to an existing file (e.g. if the tempfile already exists). 'set -C' only detects already-existing regular files, it does not prevent you writing your important data to (say) a named pipe with the right name. -- http://www.greenend.org.uk/rjk/
Re: Why back-porting patches to stable instead of releasing a new package.
Adrian Bunk [EMAIL PROTECTED] writes: If you start asking you will likely find more than thousand packages where someone will have a good reason for an update of the package in Debian 3.0. If only every 10th of these updates introduces a new bug (IMHO a conservative estimation) these packages will bring 100 new bugs into _a released stable_. Just an observation, but if every one of those changes actually fixed a bug, that'd still be a reduction of 900 bugs. (How you ensure this happens is another kettle of fish entirely.) -- http://www.greenend.org.uk/rjk/
Re: GCC 3.2 transition
Panu A Kalliokoski [EMAIL PROTECTED] writes: Richard Kettlewell wrote: I think you've answered your own question; it _can_ known which soname to use, and to discover it, it should check the version of the compiler. I'm not sure whether you're actually proposing changing the SONAMEs so that the library will compile itself with different SONAME depending on the compiler, Yes, that sounds exactly like what I'm saying. but let me say some more problems with using SONAME for the transition (even if upstream could be convinced to do this, which in practice most certainly is the biggest problem): Let's say libfoo version 17.1.6 will be the first libfoo to compile itself under libfoo.so.8 if gcc 2 is being used, libfoo.so.9 if gcc 3 is being used. You're right, this seems sensible because the libraries do have incompatible ABI's. Further releases will retain this separation. But what will happen when the library's *own* ABI (the thing SONAMEs are really meant for) changes? Will libfoo 18.0.1 install itself under libfoo.so.10 if gcc 2 is being used, libfoo.so.11 if gcc 3? That seems a reasonable approach for as long as both ABIs need to be supported. What's the problem with that? Or is support for gcc 2 to be dropped from these releases? Why should it be a library's business at all to provide information about what compiler the user programs should use, and to dictate when they cannot use compiler X anymore? This happens already; for instance, the kernel has a preferred gcc versions required to build it, and this changes from time to time. With C++ at the moment we'll probably see more of that rather than less: the older compilers don't even implement the full language correctly. So I suspect the fear of having to support multiple compiler ABIs for many years hence is unfounded in practice. The basic problem here is that SONAMEs contain insufficient information, which for example in the case of libc transition was too weak to express which other libraries the library is linked against, and now is (and should IMO not be made otherwise) too weak to tell which compiler was used to compile the library. Another variant that I think would work but haven't tried, would be to have the information encoded in the name part of the soname rather than the number, thus somewhat breaking the relationship between the name that you link against at compile time and the soname. I've never actually tried this but I believe it would work. But you can pack lots and lots of information into an integer. I think the choice of approach can be left to upstream, as long as they do _something_ to signal the ABI change. Not changing sonames[1] when the ABI changes would also be incredibly painful; bits of software that people use and depend on would start crashing. Well, it is sufficient that the linker gets the additional information from somewhere. Of the two ways (hacking the linker to use different versions depending on the ABI, or having two dynamic linkers) the latter is IMO cleaner, but neither will break anything. I'm not yet convinced that the hack the linker approach actually works properly; it requires Debian to move one set of libraries (say, those with the older ABI) to a new path. It can and may do this for libraries in Debian packages, but cannot and must not for libraries installed into /usr/local. -- http://www.greenend.org.uk/rjk/
Re: GCC 3.2 transition
Panu Kalliokoski [EMAIL PROTECTED] writes: Steve Langasek wrote: [...compiler ABI is part of library ABI...] You're right; I'm just more worried about the more practical point that if a library, when being built, cannot know which SONAME it should install itself under (it would involve checking the version of compiler used, right?), I think you've answered your own question; it _can_ known which soname to use, and to discover it, it should check the version of the compiler. It might help if gcc had a --abi option which output an ABI version, so that it wasn't necessary for every library to know all about different gcc versions, but that would be a convenience, rather than a necessity. (I believe it's also necessary to incorporate information about the sonames - i.e. ABIs - of libraries that this library depends on it, into its soname too.) changing SONAMES will be a real pain. Another possibility that didn't occur to me was having gcc somehow set the SONAME itself - but this seems to me somehow very ugly. Not changing sonames[1] when the ABI changes would also be incredibly painful; bits of software that people use and depend on would start crashing. [1] or implementing linker magic to create multiple soname spaces and using different search paths for each -- http://www.greenend.org.uk/rjk/
Re: GCC 3.2 transition
[EMAIL PROTECTED] (Martin v. Loewis) writes: Steve Langasek [EMAIL PROTECTED] writes: My concern is that locally compiled apps built against C++ libraries other than libstdc++ will silently stop working on upgrade. This is certainly not the most important issue facing us in the transition, but so far it seems to me that people are regarding it as so *un*important that it's not worth discussing at all. The breakage will not be silent: On startup of the application, they will give an error message indicating the problem. I think that problem is best solved by educating the users that such problems might happen. This is not how Debian has done similar transitions in the past: libc4 to libc5, and libc5 to libc6, did not cause this breakage in Debian. Old programs continued to work without user or operator intervention (in fact libc4 binaries still work _today_ on some Debian systems.) If you change the ABI, you change the soname. That's what it's _for_. -- http://www.greenend.org.uk/rjk/
Re: GCC 3.2 transition
Matthew Wilcox [EMAIL PROTECTED] writes: * Add a Conflict with the non-`c' version of the package. So it will be impossible to have both the old and new library packages on the system simultaneously. That's broken. Why don't we just change the sonames? Because upstream chooses the soname to match their API. If we change Sonames define ABIs not APIs. the soname then we render ourselves binary-incompatible with other distros and vendor-supplied binaries. This is important because the LSB intend to standardise the GCC 3.2 ABI; for Debian to become binary-incompatible at this point would be the height of perversity. You have to change the soname for this kind of transition to work properly and (obviously) this must be coordinated with upstream. -- http://www.greenend.org.uk/rjk/
Re: Please don't do this (code fragment)
Craig Dickson [EMAIL PROTECTED] writes: Richard Kettlewell wrote: Even if you don't care about weird platforms, x -1 is a ridiculously obscure test in this context; to achieve the same effect it would be much clearer to make x unsigned and do x = (unsigned)INT_MAX. I find x = (unsigned) INT_MAX to be more obscure than the original. When I first glanced at it, I thought, That's dumb, x is ALWAYS less than or equal to INT_MAX by definition! Then my second thought was that the cast on the constant will cause x to also be converted to unsigned. In contrast, when I saw x -1, I immediately realized it was testing for wraparound. By 'make x unsigned' I mean 'declare as unsigned int x;'. To achieve almost the same effect (probably close enough in this situation), it would be better to simply test for x INT_MAX -- it's clearer than either the original or your cast-dependent version, and only stops one iteration sooner. Since in this case the actual number of iterations was not the point (rather, merely that the loop should be guaranteed to terminate eventually), it ought to be sufficient. If we're allowed to change the meaning, there are much more sensible options still. That wasn't really the point of my post. -- http://www.greenend.org.uk/rjk/
realpath c (was Re: serious bug. Evolution and Microsoft mentality.)
Richard Kettlewell writes:
Jonathan Walther [EMAIL PROTECTED] writes:
[...]
+
+ /* follow any symlinks to the mailbox */
+ memset(folder_path, 0, sizeof folder_path);
+ if (lstat (lf-folder_path, st) != -1 S_ISLNK (st.st_mode)
+ realpath (lf-folder_path, folder_path) != NULL) {
+ g_free (lf-folder_path);
+ lf-folder_path = g_strdup (folder_path);
+ }
This code silently breaks with very long filenames. As such it can
hardly be considered a correct patch!
Of course the underlying problem is that realpath() has a ridiculously
broken interface: it insists you supply a big-enough buffer, instead
of taking an argument that indicates how big a buffer you actually
have.
Even adding the argument would still leave a poor interface though:
some systems simply don't have a sensible upper bound on path name
size, so you'd have to repeatedly call it with ever-larger buffers,
potentially invoking multiple file system accesses each time.
Rather than just whine about this, and other similarly broken pathname
manipulation functions, I've written some new versions. You can find
an overview and the (LGPL) source code at:
http://www.greenend.org.uk/rjk/2002/01/pathfns.html
I'd be interested in any comments anyone has, either on the interface
or the implementation.
ttfn/rjk
Re: How many people need locales?
Ari Makela [EMAIL PROTECTED] writes: If you take a look at even just European languages you can see that most of them cannot be written with a-zA-Z. Actually, I think only English can. It can't here, if you want to refer to the local currency in the conventional way. -- http://www.greenend.org.uk/rjk/
Re: How many people need locales?
Radovan Garabik [EMAIL PROTECTED] writes: Jean-Marc Chaton wrote: - Almost all French users (and I think I can extrapolate: all the users who need to read messages with non-ascii chars) need to set up a '/etc/locale.gen' to see them correctly for example with mutt, and that even though (and it's my case) the whole installation, menus etc is still in English for a lot a reasons. but you have to realize one thing: they are not doing it because of locale. They are doing it because they want to tell their applications to pass 8-bit characters unaffected. I don't believe it's that simple: presumably these users also want to compose messages in their native languages. As such they will need to use an editor; many editors provide operations to modify letter case (and I at least find these operations useful - so I speculate that many others will too). In general, I would expect the locale to have be set correctly for the character set in use for these operations to work. That said, some programs don't get this right even when the locale is set correctly; I can't make XEmacs 21 behave correctly, for example. -- http://www.greenend.org.uk/rjk/
out-of-date ftp.debian.org
At http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79821 you will find a discussion between the X maintainer and me. It turns out that although he had received notification that the updated package had been installed, ftp.debian.org did not reflect this. ttfn/rjk
PING of Maintainer Address richard@elmail.co.uk
I've had these messages before, and followed the instructions for stating that I no longer maintain the packages in question. But they still keep appearing. Can somebody *please* sort this out, and tell me that they have done so? (Both packages are, AFAIK, utterly obsolete and should not exist at all any more.) ttfn/rjk Brian C. White writes: PING [EMAIL PROTECTED] This address is listed as a contact for one or more Debian packages. I am just verifying that this address is functional. If you have no idea what I am talking about, please let me know as the address is obviously incorrect. Otherwise, please just delete this mail. According to the ftp://ftp.debian.org/debian/indices/Maintainers.gz file, you maintain the following packages: itimer repair If you no longer maintain one or more of these packages, please send email to Philippe Troin [EMAIL PROTECTED]. He keeps track of all orphaned packages. Brian ( [EMAIL PROTECTED] ) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: PING of Maintainer Address richard@elmail.co.uk
Just to be clear... Are they obsolete (i.e. should be removed) or are they orphaned (i.e. no longer supported)? repair was a bug-reporting script I wrote a long time ago, it never really achieve all the functionality intended and is probably out of date with respect to the modern bug system. I believe that there is another package for semi-automating bug reports anyway? It's obsolete. itimer is a package to provide interval timers for GNU Emacs. Current versions of GNU Emacs have their own timer support, therefore I believe this is also obsolete. (FWIW I still use Debian at home and at work, and hope one day to be able to contribute some more of my time to it. But I don't have the time at present.) -- Richard Kettlewell, ElectricMail Ltd phone: +44 1223 501333 fax: +44 1223 501444 [EMAIL PROTECTED] http://www.elmail.co.uk/~richard/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#4536: svgalib1 does not work with new source packaging standard
Wichert Akkerman writes: Package: svgalib1 The new dpkg-shlibdeps tries to find /usr/lib/libvga.so.1.2.8 in a package but does not find any since the .deb-file seems to contain a libvga.so.1.2.8.new instead. This breaks dpkg-shlibdeps. This seems as good an excuse as any to remind people once again that the svgalib packages could do with a new maintainer, as I currently do not have time to do further work on them. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4383: remote filesystems mounted too early
Package: sysvinit Version: 2.64-1 Remote filesystems are mounted by a command in /etc/init.d/boot. However, this runs before named is started (/etc/rc?.d/S19bind). Therefore, if hostnames are used in /etc/fstab, remote mounts fail. Remote file systems should be mounted after the name server is started. netstd_nfs or netstd_misc may be a sensible place to do this. (It's not clear to me that this is a bug in precisely one package.) -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4388: emacs mail-mode fails RFC822 section 3.4.7
Package: emacs Version: 19.34-2 I'm using Emacs under X and font-lock mode is turned on. If you write `cc:' or `Cc:' in the headers it appears in black (or the default face); however if you write `CC:' then it appears in purple. However, RFC822 headers are case-independent, so it should be the same colour independent of letter case. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4376: vm doesn't use /etc/emacs/site-start.d
Package: vm Version: 5.95beta-2 vm's postinst follows /usr/lib/emacs/site-lisp/site-start.el and modifies the file it ultimately points to in order to arrange for its initialization code to be run at startup. It should, instead, place the vm-init.el file in the directory /etc/emacs/site-start.d. When this is done it should depend on emacs being = 19.34-2 (unless someone knows earlier versions of the emacs package which have this directory.) Do not forget that upgrading to a later version of vm shouldn't cause it to install itself twice. (I'll find some time to sort all my packages out soon, honest.. l-) -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4353: fcntl.2 references nonexistent manpage
Package: manpages Version: 1.11-4 SEE ALSO open(2), dup2(2), F_DUPFD(2), F_GETFD(2), F_GETFL(2), F_GETLK(2), socket(2). but: [EMAIL PROTECTED]:richard$ man F_GETLK No manual entry for F_GETLK -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4354: movemail doesn't work
Michael Shields writes: Package: emacs Version: 19.31-2 movemail complains about not being able to write a temp file in /var/spool/mail. One fix might be to make it setgid mail, iff the code is written to be sufficiently paranoid. That's odd. [EMAIL PROTECTED]:richard$ ls -l /usr/lib/emacs/19.31/i386-debian-linux/movemail -rwsr-sr-x 1 root mail14516 Jun 3 05:05 /usr/lib/emacs/19.31/i386-debian-linux/movemail* [EMAIL PROTECTED]:richard$ (I understood that the whole point of movemail was to separate out the bit of a mailer that needed to be setgid mail into a separate executable.) -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4347: emacs html-mode + font-lock highlights too greedily
Package: emacs Version: 19.31-2 I have the following line in an HTML document: bdeny_sender/b in the brestrict.options/b file and the email However when font-lock mode is turned on, everything from deny_sender to restrict.options is highlighted, whereas the right to do is to only highlight the contents of the b.../b pairs. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4327: hsearch(3) man page patches
Package: manpages Version: 1.11-4 I suggest that the following patch be applied to ``/usr/man/man3/hsearch.3''. -BEGIN-- --- hsearch.3.orig Wed Aug 28 21:52:40 1996 +++ hsearch.3 Wed Aug 28 22:00:33 1996 @@ -29,11 +29,14 @@ .nf .B #include search.h .sp -.BI ENTRY *hsearch(ENTRY item , ACTION action ); -.RE +.BI ENTRY *hsearch(ENTRY item , ACTION action ); +.sp +.BI int hsearch(unsigned nel ); +.sp +.BI void hdestroy(void); .fi .SH DESCRIPTION -This three functions allow the user to create a hash table of type +These three functions allow the user to create a hash table of type \fIENTRY\fP (defined in \fBsearch.h\fP) which associates a key with any data. The implementation uses \fBmalloc(3)\fP. .PP @@ -41,7 +44,7 @@ \fInel\fP is an estimation of the table size which will suffice the needs. For better algorithms this value can be corrected upwards. .PP -The corresponding function \fIhdestroy()\fP frees the memory occupied by +The corresponding function \fBhdestroy()\fP frees the memory occupied by the hash table for that a new table can be constructed. .PP \fIhsearch()\fP is the function for searching and inserting. Which action @@ -51,9 +54,9 @@ and \fIFIND\fP means to only search. Unsuccesful actions result in a return value \fINULL\fP. .SH RETURN VALUE -\fBhcreate()\fP return zero if the hash table cannot be succesfully installed. +\fBhcreate()\fP returns zero if the hash table cannot be succesfully installed. .PP -\fBhsearch()\fP return \fINULL\fP if either action is \fIENTER\fP and the +\fBhsearch()\fP returns \fINULL\fP if either action is \fIENTER\fP and the hash table is full or action is \fIFIND\fP and the \fIitem\fP cannot be find in the hash table. .SH BUGS -END -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4295: majordom passwd line is wrong
/etc/passwd has majordom:*:30:30:majordomo:/var/majordomo:/bin/sh The group should be `majordom', not `majordomo'. All else aside, the correct passwd line is: majordom:*:uid:gid::/usr/lib/majordomo:/bin/sh There should be no such directory as /var/majordomo; it certainly doesn't appear in the Majordomo package, nor is it likely to do so in the near future. If it appears in any package then it is a bug in that package. I see no point in having anything at all in the comment field. The correct group line is: majordom::gid: ttfn/rjk
Bug#4307: telnet and 256+ character pastes
Package: netstd Version: 2.06-1 I pasted a 256 character string from my Emacs into an xterm running `telnet localhost' and it froze. I did the same with a 257 character string and it also froze, but didn't echo the 257th character. 255 characters did not freeze it. Connecting to other Debian systems via telnet also displays this behaviour; but rlogin does not display this behaviour. ^] quit still worked. It's these two thins that make me believe it's the telnet daemon that is at fault. muskogee:richard$ uname -a Linux muskogee 2.0.13 #1 Tue Aug 20 18:45:22 BST 1996 i486 muskogee:richard$ ldd /usr/bin/telnet libncurses.so.3.0 = /lib/libncurses.so.3.0 libc.so.5 = /lib/libc.so.5.2.18 muskogee:richard$ ldd /usr/sbin/in.telnetd libncurses.so.3.0 = /lib/libncurses.so.3.0 libc.so.5 = /lib/libc.so.5.2.18 muskogee:richard$ dpkg -l libc5 Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersionDescription +++-===-==- ii libc5 5.2.18-9 The Linux C library version 5 (run-time libr muskogee:richard$ dpkg -l ncurses3.0 Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersionDescription +++-===-==- ii ncurses3.0 1.9.9e-1 Video terminal manipulation: shared librarie -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4308: ssh and 256+ character pastes
Package: ssh Version: 1.2.13-2 I pasted a 256 character string from my Emacs into an xterm running `ssh chiark' and it froze. I did the same with a 257 character string and it also froze, but didn't echo the 257th character. 255 characters did not freeze it. Killing the session with ``RETURN ~ .'' worked. See also my recent bug report against netstd. It's possible that these two bugs are related, though I find it entirely plausible that they are separate errors. muskogee:richard$ uname -a Linux muskogee 2.0.13 #1 Tue Aug 20 18:45:22 BST 1996 i486 muskogee:richard$ su -c ldd /usr/bin/ssh Password: libz.so.1 = /usr/lib/libz.so.1.0.3 libc.so.5 = /lib/libc.so.5.2.18 muskogee:richard$ dpkg -l libc5 Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersionDescription +++-===-==- ii libc5 5.2.18-9 The Linux C library version 5 (run-time libr muskogee:richard$ dpkg -l zlib1 Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersionDescription +++-===-==- ii zlib1 1.03-1 compression library - runtime muskogee:richard$ At the server end (which has the same version of the ssh package): chiark:richard$ uname -a Linux chiark 2.0.0 #4 Sun Jul 14 00:57:42 BST 1996 i486 chiark:richard$ ldd /usr/sbin/sshd libz.so.1 = /usr/lib/libz.so.1.0.2 libc.so.5 = /lib/libc.so.5.2.18 chiark:richard$ dpkg -l libc5 Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersionDescription +++-===-==- ii libc5 5.2.18-9 The Linux C library version 5 (run-time libr chiark:richard$ dpkg -l zlib1 Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersionDescription +++-===-==- ii zlib1 1.02-3 compression library - runtime chiark:richard$ -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4267: xosview doesn't understand -geometry very well
Package: xosview Version: 1.3.2-1 I ran xosview with this command: xosview -geometry 48x48+388+0 and indeed from xlsclients -l: Window 0x282: Machine: sfere Name: [EMAIL PROTECTED] Icon Name: [EMAIL PROTECTED] Command: xosview -geometry 48x48+388+0 Instance/Class: xosview/xosview ...but (as you can see below) the window is not in the correct position: xwininfo: Window id: 0x282 [EMAIL PROTECTED] Absolute upper-left X: 392 Absolute upper-left Y: 3 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 48 Height: 48 Depth: 8 Visual Class: PseudoColor Border width: 0 Class: InputOutput Colormap: 0x26 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +392+3 -160+3 -160-399 +392-399 -geometry 48x48+390+1 Sometimes xosview positions itself near, but not exactly in, the right place; sometimes it positions itself in the upper left corner of the screen; and occasionally it even ends up in the right place. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4236: ftp(1) barfs on QUOTE command
Package: netstd
Version: 2.06-1
muskogee:richard$ uname -a
Linux muskogee 2.0.13 #1 Tue Aug 20 18:45:22 BST 1996 i486
muskogee:richard$ ftp wigwam
Connected to wigwam.elmail.co.uk.
220 wigwam.elmail.co.uk CheckPoint FireWall-1 authenticated ftp server ready
Name (wigwam:richard): richard
331-aftpd: SKEY CHALLENGE: 92 richard
331 aftpd: you can use [EMAIL PROTECTED] string
Password: I type my mojave password
200 aftpd: Enter SKEY string: you can use 'quote SKEY string' or Account
command ('ACCT')
ftp quote my skey string 92
Not connected.
ftp quit
This happens consistently. I don't know why the ftp client thinks
there's no connection - if deeper investigation is required I let me
know.
FWIW compare this with telnetting to the ftp port:
muskogee:richard$ telnet wigwam ftp
Trying 193.112.20.200...
Connected to wigwam.elmail.co.uk.
Escape character is '^]'.
220 wigwam.elmail.co.uk CheckPoint FireWall-1 authenticated ftp server ready
user richard
331-aftpd: SKEY CHALLENGE: 91 richard
331 aftpd: you can use [EMAIL PROTECTED] string
pass my password
200 aftpd: Enter SKEY string: you can use 'quote SKEY string' or Account
command ('ACCT')
my skey string 91
200-aftpd: User richard authenticated by S/Key system.
200 aftpd: Host: (use 'quote ')
mojave
421-aftpd: Connected to mojave. Logging in...
421 aftpd: aborted
Connection closed by foreign host.
muskogee:richard$
(mojave was down when I did all this but it serves to illustrate the
point...)
With Sunos 4.1.3's ftp client:
[EMAIL PROTECTED]:richard$ uname -a
SunOS tlingit 4.1.3_U1 2 sun4m
[EMAIL PROTECTED]:richard$ ftp wigwam
Connected to wigwam.
220 wigwam.elmail.co.uk CheckPoint FireWall-1 authenticated ftp server ready
Name (wigwam:richard): richard
331-aftpd: SKEY CHALLENGE: 90 richard
331 aftpd: you can use [EMAIL PROTECTED] string
Password:
200 aftpd: Enter SKEY string: you can use 'quote SKEY string' or Account
command ('ACCT')
ftp quote skey string 90
200-aftpd: User richard authenticated by S/Key system.
200 aftpd: Host: (use 'quote ')
ftp quote muskogee
421-aftpd: User [EMAIL PROTECTED] is not allowed for service ftp on muskogee.
421 aftpd: aborted
ftp
(again, this serves to illustrate the point, even if it didn't
actually work fully.)
--
Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.elmail.co.uk/staff/richard/
Bug#4222: dig in the wrong package?
Package: bind Version: 4.9.3-P1-3 `dig' really belongs in the `dnsutils' package, not the `bind' package; just because one is not running a local name server does not imply that one doens't want to use `dig' to look things up. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4220: ghostview and /etc/papersize
Package: ghostview Version: 1.5-8 When I installed this version of ghostview, it issued the message cat: /etc/papersize: no such file or directory but didn't return a non-zero exit status to dpkg, which therefore assumed that the installation had succeeded. This is two bugs. Firstly it should behave sensibly in the absence of /etc/papersize (or depend on a package which is known to provide it, though I think this is not as good an option). Secondly the postinst script ignores any errors that occur; it should include `set -e' so that errors are never ignored. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4231: acct(2) man page refers to nonexistent acct(5) man page
Package: manpages Version: 1.11-4 According to `man 2 acct': SEE ALSO acct(5) But: [EMAIL PROTECTED]:richard$ man 5 acct No manual entry for acct in section 5 [EMAIL PROTECTED]:richard$ -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: fhs
[EMAIL PROTECTED] writes: echo $HOME/Mailbox $HOME/.forward Richard Kettlewell: This is a bad idea if the home directory is NFS-mounted from a remote system; IME file locking under NFS is very easy to get wrong. (Not that all mailers get locking right even on local file systems...) This is a symptom of flaws in NFS and in the standard unix mailbox format. One possibility is to go to a more robust format (e.g. qmail's Maildir). Another possibility is to live with NFS's failures :-( I think we'll be stuck with NFS's flaws for a while yet; to ignore them would be unwise. The same remark applies to mailbox formats, though that should be easier to fix - I've not looked at qmail so I have no opinion on whether it's done it well. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: fhs
Raul Miller writes: I think you should look at this issue a bit differently. In one sense, both policies are broken -- delivering mail to a spool directory requires sgid programs for the user to read mail (in the usual sense). A more secure and more robust solution would be to deliver mail directly into the user's home directory. For example, echo $HOME/Mailbox $HOME/.forward This is a bad idea if the home directory is NFS-mounted from a remote system; IME file locking under NFS is very easy to get wrong. (Not that all mailers get locking right even on local file systems...) Additionally, a system might well have different backup or quota policies for mail and ordinary user data, which is a good reason to keep them separate. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4057: compress package install additional zcat
Yves Arrouye writes: Michael Meskes writes: Package: compress-package Version: 1.2-1 Compiling and installing the compress source found on ftp.inria.fr I get a file /usr/bin/zcat. However, gzip already install zcat in /bin. I cannot see how it's useful to have both. :-) My opinion is that gzip should *not* provide /bin/zcat but rather /bin/gzcat (and the same for other z* tools). The /bin/zcat program is just *not* zcat, it also handles gzip files which the original zcat program cannot do. I think that we should have /bin/gzcat (or even /usr/bin/gzcat because gzip only should be enough in /bin) and have /usr/bin/zcat be a symbolic link to gzcat installed by the gzip package (and not an alternative as I suggested before). And most importantly people should refrain from using zcat in scripts when the intent is to gunzip something... If gzcat was provided and /usr/bin/zcat a symbolic link to it, the zcat link would correctly be diverted by any compress-package generated package and nobody would have two semantically different zcat commands installed by installing these packages. IMHO: There should be one zcat and it should always be gzip. This won't break anything as gzip understands .Z files... Making zcat point to compress even sometimes will definitely break things; IME much of the Linux world has been assuming it's gzip for a number of years. That seems unlikely to change. compress is obsolete software; there's never any need to use it to uncompress things. Indeed, my experience (err, on Sunos rather than Linux, so this may not be relevant) is that gzip is much more reliable even at uncompressing .Z files. I can't see the need to compress things using compress either, as gzip produces smaller output, runs on pretty much everything and is free. -- Richard Kettlewell [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: Bug#2059: dpkg and depend on versions
Ian Jackson wrote: Note that means less-than-or-equal-to in this context. Could dpkg also support using = for this meaning please? (Or does it already?) Having to write to mean = is far from optimal; I think it's something we should aim to get away from at some point. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: file naming convention for debian package files (was: Re: dselect FTP method ...)
We should require a revision number for Debian packages. Imagine someone forgets to remove -g in the Makefile and doesn't strip the executable, or some other oversight happens. You need a revision number to distinguish an oversight-fix release. If that were to happen to the upstream package for a non-Debian-specific package then the upstream version number would change when it was fixed. Why not for Debian-specific packages also? Looked at that way the revision number for a Debian-specific package will never change and so would be redundant. I think the absence of a revision number is a good indicator of Debian specific packages anyway. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
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#2048: Broken pipe from dpkg to head
However: [EMAIL PROTECTED]:richard$ ls -l | head -1 total 19792 Broken pipe [EMAIL PROTECTED]:richard$ Bill Mitchell writes: PACKAGE: dpkg VERSION: 1.0.7 Script started on Mon Dec 18 21:19:37 1995 root:work# dpkg --info less*deb | head -1 old debian package, version 0.939000. Broken pipe root:work# dpkg --info less*deb x root:work# head -1 x old debian package, version 0.939000. root:work# cat x | head -1 old debian package, version 0.939000. root:work# exit Script done on Mon Dec 18 21:20:45 1995
Re: Debian+umsdos (fwd)
Bruce Perens writes: From: Simon Shapiro [EMAIL PROTECTED] And why do we want this brain dead file system (which even M$ does not use for its own 1980 eras OS's) to boot a Unix O/S with? Because it is the lowest common denominator, and it would let people alter the bootstrap floppy from a non-Linux system before they booted it. This is sometimes convenient. Since it's just the bootstrap floppy, we don't have to worry about supporting it as much as we would if we supported having the entire system on a umsdos disk. Some people are going to try that, I guess. Actually I think it would be a good thing if we could support Debian entirely over UMSDOS - being able to run Linux without having to mess around repartitioning hard discs is going to make a lot of people a lot more willing to try it. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#2043: genksyms
Okay, but the kernel makefile calls /sbin/genksyms explicitly, which is why I think *something* ought to be there. Actually I see now it is a kernel version issue: 1.2.13 calls /usr/bin/genksyms, while 1.3.47 calls /sbin/genksyms. What to do? The makefile ought to call `genksyms'. The PATH environment variable was invented for a good reason... -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: More ncurses...
and don't like to be invoked without libncurses.so.3.0 handy. Is it really ok to move libncurses.so.3.0 to libncurses.so.3.0.new in pre I thought of an obvious solution to this problem, and I'd like it shot down if possible: simply write the scripts for doing these moves in something that's guaranteed to never depend on the library. In this case, perl is the obvious answer. Am I missing something? Yes, other packages may be being operated on during the same dpkg run and they may need bash. ...and can I just mention the Curses extension to perl here? I believe under ELF it would actually be dynamically loaded are therefore not drag libncurses into perl unless you actually used it, but it's so wonderful I think it deserves a mention l-) -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: Debian+umsdos (fwd)
I've heard other reports of UMSDOS interacting badly with W95's long filename stuff. I'd put it down as a `backup first' thing for now - though I don't use either of them. umsdos with windows '95 filesystem might be a problem... With linux's msdos-fs I were not able to delete a directory; only got 'directory is not empty'-message even the directory were empty. Are you sure this is because of w95? You can also get a directory into this state using a vanilla dos file system. Umsdos has some race conditions in it that can fail to remove some of the guts of links -- these will prevent the directory from being removed until the directory has been cleaned up (e.g. mount it as an msdos file system, then use rm -rf). -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: coming soon
Bruce Perens writes: From: Ian Jackson [EMAIL PROTECTED] 1. The initrunlevel file is moving to /etc from /var/log. /var/run, surely ? /var/run is possibly in a mounted filesystem. Init breaks if it can't find this file. I've been thinking about using a named pipe so that it will work with a read-only root. You can't change run-levels if you can't write this file. Isn't it just as likely that /var/log will be on a mounted filesystem? (In fact /var is a separate filesystem on mine.) -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: coming soon
I can make symbolic links in /etc/rc.d that point back out to where the directories are instead of moving the directories. I was of the impression that real SysV worked the other way, but I can satisfy everyone. I agree with Ian. Pleas don't do this. Adding alternative paths to the same directories will only add clutter and cause confusion. BTW, I just checked and Solaris uses the same directory structure we already have. Ditto Unixware. ttfn/rjk
Re: 1.0 on Infomagic CD
Fernando Alegre writes: I think my suggestion still fits very well within your scheme. Look below: 0.93R6 - Highgate Highgate/ [contains 0.93R6] Why not having another symlink: not-released-1.0 - Holborn Yup, that'd be good. That way we would just change the name of the symlink from not-released-1.0 to release-1.0, while the actual directory would be the same. This seems to be one of the more important things. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: 1.0 on Infomagic CD
Fernando Alegre writes: On Fri, 8 Dec 1995, Bruce Perens wrote: We can't put stuff like this where just anybody can download it any longer. Especially, we can't do that and call it 1.0. This isn't entirely Infomagic's fault, in my opinion. I suggested some time ago to call the directories: release-0.93/ not-released-1.0/ Maybe it was not such a bad idea... If I might just stick my oar in on this one: As I understand it, mirrors have some trouble with directories changing names; so what we really want is a solution that keeps directory names fixed. The suggestion below suffers here in that when 1.0 is declared to be released, the directory has to change name from not-released-1.0 to release-1.0. This could be solved with a symlink, obviously, but that still leaves a directory called `not-released-1.0' containing released software, which may be felt to be suboptimal. A common practice is to give unreleased products code names. (Remember Cairo, Daytona, etc...?) If we were to adopt this scheme then the unreleased software would just be a directory with a non-obvious name; each release would have a symlink containing the version number added when it was actually released. If the 0.93R6/1.0 situation were handled like this we'd have, before the release: 0.93R6 - Highgate Highgate/ [contains 0.93R6] Holborn/[contains what will be 1.0] and after the release: 0.93R6 - Highgate Highgate/ [contains 0.93R6] 1.0 - Holborn Holborn/[contains 1.0] No renaming needed, no misleading filenames ... to find out what Highgate and Holborn were without going through symlinks you'd have to read a README which would also warn you about installing unreleased software. This idea went down quite well when discussed off-line last night - what does anyone else think? -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: 1.0 on Infomagic CD
It seems to me that a solution might be to put our real directory trees in a hidden subdirectory with a neutral name, to name those trees neutrally, and then to have meaningfully named (and easily changed) symlinks pointing to them: Something like: /debian/.hidden/debian-tree1/ # full 0.093 tree /debian/.hidden/debian-tree2/ # full 1.1 tree /debian-stable - /debian/.hidden/debian-tree1 /debian-unstable - /debian/.hidden/debian-tree2 /debian-0.93 - /debian/.hidden/debian-tree1 /debian-1.1.alpha - /debian/.hidden/debian-tree2 Then, when 1.0 becomes the stable distribution, the symlinks could change to: /debian-stable - /debian/.hidden/debian-tree2 /debian-devel - /debian/.hidden/debian-tree2 /debian-0.93 - /debian/.hidden/debian-tree1 # might be deleted /debian-1.1 - /debian/.hidden/debian-tree2 Once a debian/.hidden/treeN tree is established, it should not be renamed. That's essentially identical to what I was proposing with just two practical differences: (1) it uses numbers rather than names and (2) it goes to more effort to hide things. As to (1), I think names are better than numbers for various reasons: it's easier to remember what they mean, and it gives us the option of choosing some cute theme. As to (2), I'm not convinced about hiding things; what we actually want is for people to look in the right place for a stable version without having to think about it. If people actually want to live on the bleeding edge, it shouldn't actually be any effort to do so - just hard to do by accident. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: 1.0 on Infomagic CD
That's essentially identical to what I was proposing with just two practical differences: (1) it uses numbers rather than names and (2) it goes to more effort to hide things. May be. I'm afraid I too-hurriedly deleted the message with your suggestion, and can't go back to re-read it to see if I misread it the first time through. The intended point of my suggestion, and you might have beaten me to this, was to have the real directory trees be named neutrally, so that their names wouldn't need to change, and use symlinks with meaningful names (which could be easily changed without causing massive re-mirroring) to point to them. This is precisely what I suggested. [..] As to (2), I'm not convinced about hiding things; what we actually want is for people to look in the right place for a stable version without having to think about it. If people actually want to live on the bleeding edge, it shouldn't actually be any effort to do so - just hard to do by accident. My suggestion, and the names I chose for illustration, was intended to show a structure which allowed that. Unfortunately, I see that I inadvertantly left out a directory level in some of my illustrative namings. Let me try again, with that mistake corrected (names shown below are intended to be illustrative. perhaps there are better choices for the symlink names. In any case, the symlink names would be changeable without causing massive re-mirroring.): /debian/.hidden/debian-tree1/ # full 0.093 tree /debian/.hidden/debian-tree2/ # full 1.1 tree /debian/debian-stable - /debian/.hidden/debian-tree1 /debian/debian-unstable - /debian/.hidden/debian-tree2 /debian/debian-0.93 - /debian/.hidden/debian-tree1 /debian/debian-1.1.alpha - /debian/.hidden/debian-tree2 Then, when 1.0 becomes the stable distribution, the symlinks could change to: /debian/debian-stable - /debian/.hidden/debian-tree2 # changed from tree1 /debian/debian-0.93 - /debian/.hidden/debian-tree1 # might be deleted /debian/debian-1.1 - /debian/.hidden/debian-tree2 And no re-mirroring need occur. My comments about this remain as above. My suggestion provides the required functionality without creating `hidden' directories. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: dselect user interface (was Re: Bug#1959: binutils desc should says its necessary for gcc)
That's right. I need someone to design a completely different user interface for the package selection function in dselect. The current list interface will survive and just have - wizard mode tacked onto the menu item. Most people will use - normal mode or whatever we decide to call it. I think that the list of packages should be split up some way in order to reduce the feeling of overload one can get when looking at a list of hundreds. The current organization into sections is probably a good place to start, though cross-section dependencies may make this hard. Sections like devel are also quite crowded, so possibly there should be some other criterion (e.g. distinguishing between devel/ packages which are `standard' and those which are merely `recommended' and so on.) There should probably be a *really* dumbed down version which just asks `do you want to install the development tools' and such questions. But I think there may need to be a level between this and the current dselect as well. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Setting console font STILL broken
A friends system recently installed with Debian just booted in 80x50 and set the font incorrectly, resulting in an unreadable screen. (Only the top half of each character was displayed.) This bug has been reported at least twice before, and apparently has yet to be fixed. The fix is to edit /etc/rc.boot/console as follows. Could this bug PLEASE be fixed? ---BEGIN--- #! /bin/sh # /etc/init.d/kbd: load appropriate console font and keytable. font=default8x16 echo Console setup: echo -n loadkeys /usr/lib/kbd/keytables/uk.map #if [ -f /usr/lib/kbd/consolefonts/$font ] #then # echo -n # setfont /usr/lib/kbd/consolefonts/$font #fi ---END--- ttfn/rjk
Bug#1929: aliasinclude and forwardinclude directors missing
Package: smail Version: 3.1.29.1-13 There are no aliasinclude and forwardinclude directors in Debian's smail. This stops one from doing mailing lists. /usr/doc/smail-admin-guide/* provides examples. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#1900: tcl.h in funny location
Raul Miller writes: Package: tcl Version: 7.3 Revision: 4 tcl.h is in /usr/include/tcl -- yet there are no other files for this directory. Seems to me it would make more sense to have just plain /usr/include/tcl.h [EMAIL PROTECTED]:richard$ ls -l /usr/include/tcl/ total 219 -rw-rw-r-- 1 root root11268 Jun 17 01:56 default.h -rw-rw-r-- 1 root root21807 Jun 17 01:56 ks_names.h -rw-rw-r-- 1 root root16419 Jun 17 03:04 tcl++.h -rw-rw-r-- 1 root root22198 Jun 16 01:52 tcl.h -rw-rw-r-- 1 root root 7053 Jun 17 03:04 tclExtend.h -rw-rw-r-- 1 root root36187 Jun 16 01:52 tclInt.h -rw-rw-r-- 1 root root 831 Jun 16 01:52 tclRegexp.h -rw-rw-r-- 1 root root 6760 Jun 16 01:52 tclUnix.h -rw-rw-r-- 1 root root30427 Jun 17 01:56 tk.h -rw-rw-r-- 1 root root17207 Jun 17 01:56 tkCanvas.h -rw-rw-r-- 1 root root22643 Jun 17 01:56 tkInt.h -rw-rw-r-- 1 root root16926 Jun 17 01:56 tkText.h [EMAIL PROTECTED]:richard$ Some of these are from the tk and tclX packages, but not all: tcl /usr/include /usr/include/tcl /usr/include/tcl/tcl.h /usr/include/tcl/tclInt.h /usr/include/tcl/tclRegexp.h /usr/include/tcl/tclUnix.h tk /usr/include /usr/include/tcl /usr/include/tcl/tk.h /usr/include/tcl/tkInt.h /usr/include/tcl/tkCanvas.h /usr/include/tcl/tkText.h /usr/include/tcl/default.h /usr/include/tcl/ks_names.h tclX /usr/include /usr/include/tcl /usr/include/tcl/tclExtend.h /usr/include/tcl/tcl++.h (tcl=7.3-4; tk=3.6-4; tclX=7.3b-5; all a.out versions) -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: antisocial X11 apps: xtet42, chimera
Andrew Howell writes: Bill Mitchell writes: Dx -- dunno. Didn't take note when I had it open. I grepped /var/log/messages for a bogomips figure, but that's apparently no longer part of the startup. As I recall under earlier kernels, it was low -- perhaps 6.something. Better than the 386 I used to run, which was about 4.3. Hmmm you said it was a 40 MHz machine? but you think you get 6 something bogomips, that sounds strange. My understanding of bogomips for 486s is that it's half the clockspeed. My understanding and experience concur with this. 486DX/40 at home gives c. 20 BogoMips. 486DX2/66 at works claims c. 33 BogoMips. ttfn/rjk
Bug#1881: Majordomo UID wrong?
Karl Ferguson writes: It seems that after I installed the majordomo package it placed the folowwing entry in /etc/passwd: majordom:*:102:102::/usr/lib/majordomo:/bin/false Ok, that's fine but doing an ls -l majordomo in /var/lib produces this: drwxrwsr-x 4 101 majordom 1024 Nov 22 02:24 majordomo/ What is user 101 if I may ask? Definately no user in /etc/passwd (or on my NIS server) with UID 101. This may not be a bug, but I think there should be at least a UID 101 in /etc/passwd entry - note that 'majordom' is UID 102 [...discussion deleted...] I discussed this with Ian J. last night and there's a possibility it's a bug (or at least an infelicity ;-) in dpkg. Majordomo 1.93-2 will (a) get it right and (b) should fix any broken installation of 1.93-1 that may be around. I should get around to uploading it this evening or tomorrow. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: Bug#1881: Majordomo UID wrong?
brian white writes: It seems that after I installed the majordomo package it placed the folowwing entry in /etc/passwd: majordom:*:102:102::/usr/lib/majordomo:/bin/false What is supposed to happen is that the preinst creates a group and user for majordomo; files are supposed to be in the .deb file owned by user majordom and group majordom, and represented in the tar file inside the .deb file by text strings - so that they get set to whatever numeric values were set up by the preinst. How is this userid determined? I've been talking with Ian and Bruce to get a fixed userid allocated for gnats because it needs a common id across all machines on which it is used. They are going to reserve me an id just for this purpose. The preinst calls adduser. The package is supposed to then use whatever uid/gid it finds in the passwd/group files. When I announced my intention to create a Majordomo package I posted to debian-devel asking about acquiring a fixed uid/gid pair for it (which would have made the job of Debianising it slightly easier). The only response was the suggestion that it could be allocated on the fly, so I did that. To my knowledge there's no strict requirement that Majordomo use the same uid/gid on every machine. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#1881: Majordomo UID wrong?
Karl Ferguson writes: The preinst calls adduser. The package is supposed to then use whatever uid/gid it finds in the passwd/group files. Are you forgetting NIS (Yp) systems? If I had already a UID 101, and it decided to add user 101 would this conflict? If that happens it's a bug in adduser, which is what chooses the uid/gid pair, not Majordomo. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#1878: bind doesn't purge named.boot
Package: bind Version: 4.9.3-BETA24-1 The postrm script doesn't remove the named.boot file when you run dpkg --purge on the package. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#1656: etc/ntp.dFrom @mongo.pixar.com:debian-devel-request@Pixar.com Tue Nov 21 23:34:18 1995
Karl Ferguson writes: It seems that after I installed the majordomo package it placed the folowwing entry in /etc/passwd: majordom:*:102:102::/usr/lib/majordomo:/bin/false Ok, that's fine but doing an ls -l majordomo in /var/lib produces this: drwxrwsr-x 4 101 majordom 1024 Nov 22 02:24 majordomo/ What is user 101 if I may ask? Definately no user in /etc/passwd (or on my NIS server) with UID 101. This may not be a bug, but I think there should be at least a UID 101 in /etc/passwd entry - note that 'majordom' is UID 102 Yes, it is a bug. What is supposed to happen is that the preinst creates a group and user for majordomo; files are supposed to be in the .deb file owned by user majordom and group majordom, and represented in the tar file inside the .deb file by text strings - so that they get set to whatever numeric values were set up by the preinst. Physically examining the tar file from the .deb I uploaded reveals that it does, indeed, have the text values of the user name and group name. You will probably find majordomo doesn't work very well unless you chown anything owned by user 101 to be owned by majordomo. Is there a group with gid 101 on your system? What is the gid of the majordom group on your system? This needs some experimentation. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Re: Bug#1834: [kubla@goofy.zdv.Uni-Mainz.de: /etc/profile on Debian Linux]
Steve Greenland writes: [/etc/profile suggestion] if [ -f $HOME/$ARCH-linux ]; then PATH=$HOME/$ARCH-linux:$PATH else mkdir $HOME/bin 2/dev/null PATH=$HOME/bin:$PATH fi I don't think /etc/profile should be creating directories in my home directory. Agree. They should be created when the account is created, or (IMHO better) not at all. I think if is someone is sufficiently Unix literate to be adding their own commands, they can probably make the appropriate modifications to PATH in their own .profile. Maybe put PATH=$HOME/bin:$PATH in the skel version, commented out? I don't see any harm in including the directory in the PATH even if it's not there. Or even do if test -d $HOME/bin; then PATH=$HOME/bin:$PATH;fi ttfn/rjk
Bug#1806: genksyms misplaced?
Bill Hogan writes: Packages: devel/source, base/modules Versions? Problem: base/modules installs genksyms as `/usr/bin/genksyms', kernel Makefile[?] looks for `/sbin/genksyms'. Wasn't this reported ages ago? I can't find anything in the bug report logs, however. genksyms ought to be in /usr/bin, not /sbin; you don't need before you've mounted /usr, and it's perfectly possible that non-administrative users might want to use it e.g. when compiling their own kernel. The Makefiles should just look for it as `genksyms' without specifying a path at all. ttfn/rjk
Re: inverse of `adduser'?
* what if the user has processes running? Or a print job queued? Or mail queued? Life is too short to worry about this. Actually I should have written `kill any processes the user owns' without opening that point to discussion since leaving them running has obvious security problems. Maybe it should be possible to delete everything from the home directory except a .forward file. Actually, in my shop we don't allow .forward files to remain for [...] Fair enough, though I'm inclined to think that this should be a local decision. ttfn/rjk
Re: inverse of `adduser'?
Bill Mitchell writes: * what about files owned by this user in other directories? (Shared projects, etc.) We tend to leave them as-is, which I'm not sure is smart. On the other hand, a find from / is expensive on a system with lots of disk... Finding the files and expunging them Um, I was thinking more of arranging for them to be changed to another uid, or at least telling the sysadmin they exist - leaving them as they are risks trouble when some new user is created. If I leave the company I work for I'm sure they won't want to delete all the files I worked on in shared directories. should probably be an option for deluser (which, IMO, should be adduser -d or adduser --delete). *shrug* Let the sysadmin using it decide whether that's too expensive for him, in his situation. Don't make the decision for him and expect him to like it. Agreed. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#1532: no revision number with repair
Erick Branderhorst writes: Repair seems to be searching in the file /var/lib/dpkg/available to find some info about the specific package. It however never seems to find the debian revision number. I took a quick look in the script and it seems to search for a sequence package_revision. In the /var/lib/dpkg/available the keyword revision is used. In the control file of a package the keyword package_revision (case insensitive) should be used. Some inconsequence is spotted here. Perhaps this is a bug? in dpkg. The next version of repair, which isn't quite ready yet, calls dpkg to find information about the package rather than make assumptions about the format of internal databases; I'll check that it looks for the right field name tonight. There are one or two other things that need to be resolved before I upload it. Thanks for taking the time to have a look at it! -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
