Bug#2868: amd hangs on tcsh hostname completion
Could you please check that this is still true in the latest release? Thanks, Dominik
Bug#3988: Kbd: missing Dvorak keyboard maps
The missing maps will be incorporated in the next release. Thanks for providing the necessary information. Dominik
Bug#3838: GCC should depend on CPP, not conflict with it
Ian Jackson writes: David Engel writes (Re: Bug#3838: GCC should depend on CPP, not conflict with it): Ian Jackson writes: ... Hmm. Why is it necessary for gcc to know which version of cpp is available, or for it to have exactly the right one ? Would you want the front-end driver (gcc) to use different versions of cpp and cc1/cc1plus? Forgive my naivete', but I don't see why it should matter. Because they're designed to work together. That's why the FSF includes cpp with gcc instead of packaging it separately. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Bug#4088: ghostview does not put filename in window title
Package: ghostview
Version: 1.5-8
This is a change request: I would very much like ghostview to put the
filename (or document title) in the X window title. This will make it
much easier to pick the right ghostview window out of a list.
In fact, I wanted this so much I went and implemented it :-). The
patch is below. The new feature is optional, but enabled by default.
Ian.
diff -ru ghostview_1.5-8.dist/ghostview.man ghostview_1.5-8/ghostview.man
--- ghostview_1.5-8.dist/ghostview.man Sat Jul 24 03:29:12 1993
+++ ghostview_1.5-8/ghostview.man Fri Aug 9 20:19:57 1996
@@ -463,6 +463,9 @@
.IP \fBshowTitle (\fPclass\fB Labels)\fP 1i
Tells whether to display the \fB%%Title\fP comment.
The default is ``true''.
+.IP \fBwindowTitle (\fPclass\fB Labels)\fP 1i
+Tells whether to copy the \fB%%Title\fP comment into the window title.
+The default is ``true''.
.IP \fBshowDate (\fPclass\fB Labels)\fP 1i
Tells whether to display the \fB%%Data\fP comment.
The default is ``true''.
@@ -623,6 +626,10 @@
Equivalent to setting ``Ghostview.showTitle: True''.
.IP \fB\-notitle\fP 1i
Equivalent to setting ``Ghostview.showTitle: False''.
+.IP \fB\-wtitle\fP 1i
+Equivalent to setting ``Ghostview.windowTitle: True''.
+.IP \fB\-nowtitle\fP 1i
+Equivalent to setting ``Ghostview.windowTitle: False''.
.IP \fB\-date\fP 1i
Equivalent to setting ``Ghostview.showDate: True''.
.IP \fB\-nodate\fP 1i
diff -ru ghostview_1.5-8.dist/gv.h ghostview_1.5-8/gv.h
--- ghostview_1.5-8.dist/gv.h Sat Jul 24 03:29:12 1993
+++ ghostview_1.5-8/gv.hFri Aug 9 20:17:56 1996
@@ -39,6 +39,7 @@
/* Application resources */
typedef struct _AppResources {
Boolean show_title;/* whether to show title */
+Boolean window_title; /* whether to put document title in window
title */
Boolean show_date; /* whether to show date */
Boolean show_locator; /* whether to show locator */
Boolean auto_center; /* whether to automatically center the page */
@@ -103,6 +104,8 @@
extern XErrorHandler old_Xerror;
extern Boolean dying;
extern XErrorEvent bomb;
+extern XTextProperty nameprop;
+extern String version;
enum {OPEN, PRINT_WHOLE, PRINT_MARKED, SAVE};
extern int mode;
diff -ru ghostview_1.5-8.dist/main.c ghostview_1.5-8/main.c
--- ghostview_1.5-8.dist/main.c Sat Jul 24 03:29:12 1993
+++ ghostview_1.5-8/main.c Fri Aug 9 20:43:53 1996
@@ -55,11 +55,13 @@
extern char *getenv();
-static String version = Ghostview, version 1.5;
+String version = Ghostview, version 1.5;
static XtResource resources[] = {
{showTitle, Labels, XtRBoolean, sizeof(Boolean),
XtOffsetOf(AppResources, show_title), XtRImmediate, (XtPointer)True},
+{windowTitle, Labels, XtRBoolean, sizeof(Boolean),
+ XtOffsetOf(AppResources, window_title), XtRImmediate, (XtPointer)True},
{showDate, Labels, XtRBoolean, sizeof(Boolean),
XtOffsetOf(AppResources, show_date), XtRImmediate, (XtPointer)True},
{showLocator, Labels, XtRBoolean, sizeof(Boolean),
@@ -138,6 +140,8 @@
{-page, .page, XrmoptionSepArg, NULL},
{-title, .showTitle, XrmoptionNoArg, True},
{-notitle, .showTitle, XrmoptionNoArg, False},
+{-wtitle, .windowTitle, XrmoptionNoArg, True},
+{-nowtitle, .windowTitle, XrmoptionNoArg, False},
{-date, .showDate, XrmoptionNoArg, True},
{-nodate, .showDate, XrmoptionNoArg, False},
{-locator, .showLocator, XrmoptionNoArg, True},
@@ -287,6 +291,7 @@
XErrorHandler old_Xerror; /* standard error handler */
Booleandying; /* whether an X error caused our exit */
XErrorEventbomb; /* what the error was */
+XTextProperty nameprop; /* the XStringProperty for the window name */
XtAppContext app_con;
AppResources app_res;
@@ -363,7 +368,6 @@
Boolean set_vert_dist;
String s1, s2;
XFontStruct *font;
-XTextProperty nameprop;
Dimension bottomMargin, leftMargin, rightMargin, topMargin;
Dimension width, height;
Dimension button_width;
@@ -371,6 +375,7 @@
static XawTextSelectType sarry[] =
{XawselectLine, XawselectAll, XawselectNull};
+nameprop.value= 0;
XtToolkitInitialize();
XtSetTypeConverter(XtRString, XtRPageOrientation,
XmuCvtStringToPageOrientation, NULL, 0,
@@ -871,7 +876,7 @@
XtSetArg(args[0], XtNtransientFor, toplevel);
XtSetValues(dialogpopup, args, ONE);
XSetWMProtocols(dpy, XtWindow(toplevel), wm_delete_window, 1);
-if (XStringListToTextProperty(version, 1, nameprop)) {
+if (nameprop.value) {
XSetWMName(dpy, XtWindow(toplevel), nameprop);
}
diff -ru ghostview_1.5-8.dist/misc.c ghostview_1.5-8/misc.c
--- ghostview_1.5-8.dist/misc.c Sat Jul 24 03:29:12 1993
+++ ghostview_1.5-8/misc.c Fri Aug 9 20:43:43 1996
@@ -297,6 +297,7 @@
static String nothing = ;
String label;
Pixmap bitmap;
+char *title, *versionfilename;
/* Reset to a known state. */
Re: dpkg-changelog-mode (dpkg-changelog.el)
Michael Meskes writes (Re: dpkg-changelog-mode (dpkg-changelog.el)): Do we have an official look the changelog has to have? If so how should it look? I won't be able to test your emacs style since I don't use emacs. Yes, we do. An example (from dpkg) is below. This is documented both by example in hello and dpkg and by specification in the new manual. Ian. dpkg (1.3.1) experimental; urgency=LOW * manpage for dpkg-source et al now available. * dpkg-changelog-mode.el installed in site-lisp, but still no autoload. * dpkg-source prints correct string for not-understood tar -vvt output. * dpkg-source parsing of tar -vvt output made more robust. * dpkg-buildpackage prints usage message on usage error. * dpkg-gencontrol can print usage message. * -Tvarlistfile option added to dpkg-source. * Description of -ffileslistfile corrected in dpkg-distaddfile usage. * -mmaintainer synopsis changed in dpkg-genchanges usage. * debian/substvars may now contain blank lines. -- Ian Jackson [EMAIL PROTECTED] Thu, 8 Aug 1996 02:36:04 +0100
Caldera's lawsuit against Microsoft
I should think that you've all heard about this by now - if not go and look at comp.os.linux.announce. I'm just posting here on what's really an irrelevant topic to say that I think it's a very good thing that someone is challenging Microsoft. I mailed Lyle Ball at Caldera to tell him so, and he thanked me for my support and said: Please be vocal about your opinions on this case, especially on the forums. So, here I am in my favourite forum :-). If you want to discuss this somewhere here probably isn't it. Ian.
Re: Alphas and libc dependencies
Miquel van Smoorenburg writes (Re: Alphas and libc dependencies): You (Ian Jackson) wrote: ... 2a. Give the package containing our version of glibc version 0 the name libc5. 2b. Implement version numbers for virtual packages so that we can use one here. I think 2b should be done; [...] if this would work: Provides: libc5_5.2.18-8, ldso_ 1.7.14-4, timezone_7.48-3, libdb1_1.85.2-8, libgdbm1_1.7.3-11 it would solve a huge problem. The problem is that this is quite a significant amount of work, and I don't really have time to deal with it now. (Incidentally, the syntax would be `Provides: libc5 (5.2.18-8), ldso (1.7.14-4)' c.) ... Would it be very hard to put this in dpkg? Oh and would you like to have the Alpha patches for dpkg first so you can integrate them into the normal version (would make it easier for me). Certainly you should send me your patches. IME architecture patches fall into two categories: bug fixes where I made a mistake (which I'll fix straight away if I can, for example by using your supplied patch) and workarounds for architecture-specific braindamage. I've had some problems with the latter and m68k and ELF, and I have to say that I'm very reluctant to put in `workaround' patches. You have been warned :-). Ian.
Bug#4089: problems with rc.local
Package: base Version: 1.1 The file '/etc/rc.local' exists, but is not set up properly. - It has permissions 644 instead of 744 - It is called only by '/etc/init.d/compat' but this file does not appear to be linked into any of the rc directories. (compat also runs the file '/sbin/setup.sh') Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: fileutils can now replace perforate...
Mark Eichin writes (Re: fileutils can now replace perforate...): [Ian Jackson:] But --sparse=auto is impossible to implement correctly on many systems, and filesystem-dependent on others ! Depends on what you mean by sparse... the trick is that you can use stat() to determine if the file has *any* holes. No, that's precisely what I'm claiming *can't* be done, because of indirect blocks amongst other things. IMO cp should either always produce sparse files by default or never do so by default, not some half-way house that guesses and will get it wrong sometimes. Ian.
Re: Alphas and libc dependencies
Miquel van Smoorenburg writes (Re: Alphas and libc dependencies): ... In addition to my last message, here is an alternative I've just though of. Why don't we just provide dummy (eg empty) libc5, libdb1 etc packages, and let libc6 depend on them. Then libc5 etc _will_ be installed.. I think that's what I'll do until Ian has implemented version numbers for virtual packages (if that's a reasonable solution that is). Well, it's not ideal - in particular, it means that you can deinstall libc6 when you clearly ought not to. How about doing it the other way around - having an empty libc5 package which depends on libc6 ? This is obviously a bit of a nasty hack, but it will have the right effect. Ian.
Re: Emacs per-package startup files
[EMAIL PROTECTED] writes (Re: Emacs per-package startup files): Umm, /usr/lib/emacs/site-lisp/ is already there, and already the right place for this sort of thing. Next question? Err, I don't think so. Files in /usr/lib/emacs/site-lisp aren't loaded automatically (and shouldn't be). As for ordering: use require, and then safe-append a section to /etc/site-start.el, JUST LIKE EVERYTHING ALREADY DOES... we don't need a new mechanism here, just some common simple automation of the one that vm, w3, gnats, and others already use... Respectfully, I disagree. Experience with /usr/info/dir, inetd.conf, and indeed with site-start.el (/etc/site-start.el vs. site-lisp/site-start.el and symlinks, c) has taught us, I feel, that it is a bad thing to have many different packages all dynamically update the same file just to add and remove their own little bits from it. Contrast this with /etc/rc?.d and /etc/rc.boot, where there has been little unfortunate interaction. There's the question of how to distinguish changes made to the shared file by the sysadmin from those made by package maintainer scripts. This is much easier if each package's bit is in a separate file - dpkg's conffiles mechanism can take care of it. There's also the question of having a standard tool. Obviously it would be good to have a standard tool for this kind of thing (a la install-mime and the rest). However, the more you do this the more of these little install-foo scripts you have, and the more stuff you drag in when you try to install the package. For example, supposing Emacs were to provide a script to add things automatically I couldn't use it, because dpkg can't depend on Emacs. The script would have to end up in dpkg itself. So, all in all, I think it would be better to have an arrangement where all the bits that packages would want to put in the site-start are installed as conffiles in a directory, and arrange that the real site-start runs every file in the directory a la run-parts. As for ordering: the entries in site-start aren't supposed to require much ordering. After all, they're autoload definitions and the like. I think a sequence numbering scheme like that for the other package-put-a-file-in-here directories would be quite adequate. Now Emacs is your (Mark Eichin's) package, so you get to decide how things are to be done. I still hope though that I (and others who may agree with me) can persuade you that these arguments have merit, and that it would be better and simpler in the long run if we started making this not particularly arduous transition. Either way I'd appreciate it if, when this discussion is concluded, you could send me some text for the new policy manual about how elisp should be managed. Thanks, Ian.
Re: Bug#3984: NIS writes error message to STDERR
Miquel van Smoorenburg writes (Bug#3984: NIS writes error message to STDERR): ... This is a bug in the library; the library routines print this (they shouldn't ofcourse). Heeemmm can anybody tell me how to redirect a bug report to another package, libc5 in particular? Yes. [EMAIL PROTECTED]' can. As can http://www.cl.cam.ac.uk/users/iwj10/debian-bugs/. Or ftp://ftp.debian.org/debian/doc/bug-*.txt. I can too, but I think you should RTFM. Ian.
Re: New virtual package names.
Dale Scheetz writes (Re: New virtual package names. ): ... On another note, is there an editor virtual package? Is there any interest in adding one? It could be valuable to add Provides: editor to ae (and others as well). Sorry I'm coming into this so late (just over a week, in fact), but I think this is a daft idea. Noone is going to deinstall all the editors on their system and not notice what they've done wrong and how to fix it - this is not the kind of `mistake' our dependency scheme should try to address. The only possible consequences of creating an `editor' virtual package and having things depend on it are: * Needless updates to packages to add dependencies and Provides * Some person installs their own favourite editor in /usr/local and wants to remove all ours but can't. I think the `editor' virtual package should be scrapped. Ian.
Re: Name clash in prospective package
Lars Wirzenius writes (Re: Name clash in prospective package ): ... For instance, there's no guarantee that /usr/local/lib exists, or that the admin wants it to exist, or that it won't cause any trouble if it does exist. I can't think of anything that would break, but admins are allowed to do funny things in /usr/local. The problem with this strict approach is that we want (for obvious reasons) our tools to search local directories too when looking for commands, Perl modules, lisp files or whatever. Therefore we can't avoid making some assumptions about what's in /usr/local. The point of not putting things in /usr/local isn't, as I see it, so that the sysadmin can put a baroque thing there and have everything work - it won't - but so that they can put their own software there (installed well or badly) without fear of it being destroyed by the packaging system. ... I quite agree that it should be easy to set up such complex things [like directory structures c in /usr/local], but not without asking. I don't think we need to bother the user with one more question, if we provide a way for an expert to have us leave /usr/local alone. I propose the following resolution: * A policy that packages should include in their .deb files empty directories for path-searched directories. Files are not allowed, and packages aren't allowed to touch /usr/local at all in their maintainer scripts. * When dpkg has the `ignore files matching pattern' option (this will be read from a configuration file) you'll be able to stop it installing things in /usr/local at all. I'm afraid this will be a while coming, but in principle it's not too hard. Ian.
Bug#3991: dselect has confusing and bizarre interface
Daniel Quinlan writes (Bug#3991: dselect has confusing and bizarre interface): [ complaints about dselect's user interface ] I am merging this with Bug#1037. Offers of assistance are welcome. Ian.
Debian, Linux, the FSSTND, the FHS and BSD
(Note: this message is crossposted between two mailing lists - you should probably follow up on only one.) What used to be the FSSTND group has changed composition somewhat, and now includes a number of people from the BSD world. It set itself the goal of producing a joint filesystem layout standard, named the FHS. I argued against many of the changes that were proposed, on the grounds such as the disruption that would be caused to the Linux community by moving things or the fact as I saw it that the FSSTND's arrangements were cleaner and that we should not compromise, moving things to messier locations, because BSD had done it that way. I lost this argument, chiefly through a combination of poor politics on my part and the fact that there were more people who seemed willing to make major sacrifices for compatibility with BSD. The latest draft FHS, which they may well publish as it stands, makes the following changes with which I have very strong disagreements: * The mail spool, /var/spool/mail, is moved to /var/mail. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. * A new directory /usr/libexec is created to hold command binaries used only internally by programs - these are to be moved from /usr/lib and in some cases /usr/sbin. Oddly there is no corresponding /libexec directory. The two good changes that I see are (and they are not minor): * /usr/share exists and is defined. * /opt exists and is defined. I have spent an awful lot of time and energy on the FSSTND mailing list, and I do not have any left with which to further persue this matter there in the face of the very considerable amount of bad feeling which exists. It pains me greatly to say this, given my emotional investment in the work of the FSSTND, but: if the FHS draft is promulgated as it stands I shall not support its adoption by the Debian project. It looks like we (Debian) are going to need /opt, and possibly /usr/share. We can take those parts if we need them. I'm posting this message so that: (a) The rest of the Debian Project can decide what they want to do. If the consensus is that they wish to follow the new standard then I shall be unhappy, of course. I don't know what my reaction would be in terms, for example, of my authorship of dpkg and of the Debian Project policy manual. Disillusionment, I suppose. (b) The newly-renamed FHS group can reconsider - though I doubt that they will. They'll see this as an attempt by me to blackmail them. For the Debian people: the latest draft can be found on tsx-11.mit.edu in /pub/linux/docs/linux-standards/private/fsstnd/. Ian. [1] When the original FSSTND was created I argued in favour of /libexec and /usr/libexec, but lost that debate. I'm less convinced now than I was then, but my main reason for opposing it now is that it is too late to change.
Amaya package
Hello, I'd like to ask to be in charge of a Debian package for Amaya, which will go public in the next weeks. Amaya is a WWW WYSIWYG editor/browser supporting structured edition and cascading style sheets among other features. It is realized by the W3C as was Arena. I'd like to maintain this package because I know people working on Amaya, and really would like to do this package. Thanks, Yves.
Re: Documentation formats
Ian, I am aware of your efforts with linuxdoc.sgml, and I think it's important to make it clear that HTML is only the end-product. It's fine to encourage people to use linuxdoc as a source language. Thanks Bruce
Re: Pb: gdb cannot read core from 2.0.8 (is it a gdb or kernel problem)?
You (Yves Arrouye) wrote: GDB 4.15.1 (i486-linux), Copyright 1995 Free Software Foundation, Inc... 0¨´ @/core: not in executable format: File format not recognized So there's a problem there. Do you have an idea about who is faulty? Gdb? As I understand it, the way you call gdb is gdb [executable] [its core file] preferrably with [executable] compiled with -g and linked statically I doubt that gdb can read core files without an accompanying executable.. Mike. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Re: epoch?? how to make squid-1.0.5 squid-1.0beta16
Craig Sanders writes (epoch?? how to make squid-1.0.5 squid-1.0beta16): ... Was epoch implemented? How do I use it? Yes. See the draft programmers' manual. Ian.
Re: Replaces: and virtual packages?
Yves Arrouye writes (Replaces: and virtual packages?): I thought having a package with Provides: compress Replaces: compress would be like Provides: compress Conflicts: compress except that the conflict will not appear and I hoped that when the package was installed any previous package providing compress would be removed first. I think you want: Conflicts: compress Replaces: compress Provides: compress Ian.
Re: Is it okay to download orig source once only?
Yves Arrouye writes (Is it okay to download orig source once only?): ... I propose that we upload once somepackage_release.tar.gz which unpacks to somepackage-release.orig/ and then further uploads would be somepackage_release-deb.diff.gz somepackage_release-deb_arch.deb Would that be okay? Not at the moment, no, because the .tar.gz is the debianised source. However with the new source package format this is possible in principle, though in practice there are a few technical issues with dpkg-source to be sorted out. Ian.
Bug#4090: /etc/init.d/kerneld uses grep
Package: modules
Version: 2.0.0-6
The script /etc/init.d/kerneld uses grep - which might not be available. The
problem is that if you put `auto' into /etc/conf.modules, kerneld is started
before any extra mounts are done. So if you have /usr on a separate partition,
/usr/bin/grep (which is where grep lives) is not yet available.
Possible solution: If /etc/init.d/kerneld accepts `auto' as an argument, it is
possible to distinguish if it is called by /etc/init.d/modules or as part of
the links in one of the /etc/rc?.d.
I include a patch which works on my system which does the following:
- /etc/init.d/modules calls /etc/init.d/kerneld with the argument `auto'
instead of `start' if the keyword `auto' is found in /etc/conf.modules.
- /etc/init.d/kerneld interprets `auto' like `start', except that it skips the
test if the keyword `noauto' is present in /etc/conf.modules
Feel free to use the patch if you like my solution and if my patch looks ok to
you.
Cheers,
Lukas
--- modules.origFri Aug 9 16:55:11 1996
+++ modules Fri Aug 9 16:55:33 1996
@@ -34,7 +34,7 @@
do
case $module in
auto) [ ${startkerneld} -eq 0 -a -x /sbin/kerneld ] \
- echo /etc/init.d/kerneld start startkerneld=1;
+ echo /etc/init.d/kerneld auto startkerneld=1;
continue ;;
noauto) continue ;;
\#*|) continue ;;
--- kerneld.origFri Aug 9 16:53:26 1996
+++ kerneld Fri Aug 9 16:54:57 1996
@@ -6,7 +6,9 @@
test -f /sbin/kerneld || exit 0
# Check if noauto is set
-grep ^[ ]*noauto /etc/modules 21 /dev/null exit 0
+if [ $1 != auto ]; then
+grep ^[ ]*noauto /etc/modules 21 /dev/null exit 0
+fi
KDOPT=
@@ -14,7 +16,7 @@
[ -d /lib/modules/`uname -r` ] || exit 0
case $1 in
- start)
+ start|auto)
#
# is /proc mounted ?
#
---
Dr. Lukas Nellen | Email: [EMAIL PROTECTED]
Depto. de Fisica Teorica, IFUNAM |
Apdo. Postal 20-364 | Tel.: +52 5 622 5014 ext. 218
01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
Bug#4091: Ftp does not wait for user answers on mget
Package: netstd Version: 2.05-1 The ftp command, at least in a xterm, does not let one stop mget: ftp mget x* mget xarclock_1.0-1.deb? Continue with mget? mget xautolock_pl10-2.deb? Continue with mget? mget xaw3d_1.2a-5.deb? Continue with mget? mget xbase_3.1.2-9.deb? Continue with mget? mget xbmbrowser_4.2-2.deb? Continue with mget? mget xcolors_1.5-2.deb? Continue with mget? mget xcompat_3.1.2-4.deb? Continue with mget? mget xcontrib_3.1.2-1.deb? Continue with mget? mget xdaliclock_2.06-1.deb? Continue with mget? mget xdevel_3.1.2-4.deb? Continue with mget? mget xearth_1.0-11.deb? Continue with mget? mget xfnt100_3.1.2-6.deb? [etc...] After having displayed 'Continue with mget?' it gets to the next file asking, so there's no chance to answer no. (In the example above, I hit C-c on each line). Yves. --
Re: gcc and binutils
Bernd Eckenfels writes (gcc and binutils): ist it possile that on a fresh new install gcc is installed before binutils is installed, and therefore fail to configure? If I run configure afterwards everything is fine. Will dpkg install a package first if it sees that other ones depend on it? Err, I don't quite understand the question. The answer to your first sentence is `no, it shouldn't be possible'. See the draft programmers' manual for details of exactly how things happen. Ian.
Re: Draft manuals
Raul Miller writes (Re: Draft manuals): Some thought about qmail should occur [in the section on mail processing]. qmail doesn't use a mail spool directory for security reasons, mail boxes are in the user's home directory by default. And, of course, there's the maildir format for people wanting a very robust system. I've seen mention on debian-devel of making movemail aware of maildir. I suspect that this is the right thing to do. qmail's author has taken a deliberate choice to be incompatible with things, and this means that we can either: * mandate that everything support what qmail does * live with not everything working when you use qmail. What precisely do you think I should put in the policy manual on this subject ? I'm loath to mandate that every program support qmail's maildir format. Perhaps the qmail package should come with a local delivery agent that can do delivery into /var/spool/mail ? It only has to be setgid mail, not setuid root. That requirement would be the effect of the policy requirements as they're written atm. Ian.
Re: /usr/doc/copyright/package - /usr/doc/package/copyright ?
Erick Branderhorst writes (Re: /usr/doc/copyright/package -
/usr/doc/package/copyright ?):
...
But a /usr/doc/copyright dir should remain. The only contents allowed in
there would be generic copyright messages like GPL LGPL BSD and so on.
Putting these generic files in /usr/doc/base/{GPL,LGPL,BSD} is not wise
IMHO. Additionally because translated version of the above generic
copyright messages are on the net and it might be usefull to put these
translations there as well. This specific group of files justify to have a
directory for them selves IMHO. I don't mind that these are gzipped.
That seems reasonable to me. We should leave a README there pointing
people to /usr/doc/package/copyright.
Ian.
Bug#3838: GCC should depend on CPP, not conflict with it
David Engel writes (Re: Bug#3838: GCC should depend on CPP, not conflict with it): ... Because they're designed to work together. That's why the FSF includes cpp with gcc instead of packaging it separately. This doesn't much sense to me, at least not without more detail. Why do gcc and cpp need to know each other's particular versions ? There are lots of other things that are designed to work together where a bit of version slippage doesn't matter. Ian.
sgmlspm 1.03ii-1: initial experimental release
This is the Perl5 module that I've been using to support my dpkg manual processing backends. Because it's in the new source format and refers to an as-yet-nonexistent virtual package I'm sending it into experimental. -BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sat, 10 Aug 1996 01:47:30 +0100 Source: sgmlspm Binary: sgmlspm Architecture: source all Version: 1.03ii-1 Distribution: experimental Urgency: low Maintainer: Ian Jackson [EMAIL PROTECTED] Description: sgmlspm- Perl modules for processing SGML parser output Changes: sgmlspm (1.03ii-1) experimental; urgency=LOW . * Initial Debian release. Files: 470ebffa5f64d0dbd2e8a68e2ae2bdbf 607 text optional sgmlspm_1.03ii-1.dsc 6813acffaa1d2798908ce28725604a9c 92641 text optional sgmlspm_1.03ii.orig.tar.gz 6185b1db8fcf734dc19f34d1293a8d32 2250 text optional sgmlspm_1.03ii-1.diff.gz 5219d462920b220fe2722bfefe11628c 50830 text optional sgmlspm_1.03ii-1_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMgvcRMMWjroj9a3bAQHlPQQA8F1h+XsuKtCDIoEpnkvA1sfxrA0xbxZ6 jySHyKiy5Y28DFXKO0J9jWf/PhoNm0G8CGq3vGGG4tgxGPBc9ShgWbmhwtMnT0oP osuhGO5B/HKgfhnB0RnWj96TiZK0Oepe3vqSFLBhdk2W7HSschI+TiWUvQPUhY6u 1s49DUE6tdM= =d3fB -END PGP SIGNATURE-
Bug#2868: amd hangs on tcsh hostname completion
Yes, it is. I am using the latest debian stable distribution.
Simply cd to /n (which is mapped to the following amd.host contents:
/defaults opts:=grpid,intr,nosuid,rsize=8192,wsize=8192
* host==${key};type:=link;fs:=/ || type:=host;rhost:=${key}
)
and type 'ls' there. It will just hang when you do that. Then, when I
compiled my own amd from upl67 from sunsite, the problem went away.
On Fri, 9 Aug 1996, Dominik Kubla wrote:
Could you please check that this is still true in the latest release?
Thanks,
Dominik
Re: Qmail, smail and sendmail
Ian Jackson writes: Yves Arrouye writes (Qmail, smail and sendmail): Does qmail support /etc/aliases, have a newaliases command and support being called as sendmail with the -bi option? The same questions may be asked for smail. Well, perhaps we should just say that you can edit /etc/aliases and must run newaliases afterwards if it exists. That's what I do. I even run sendmail -bi if newaliases is not found. But I wanted to be sure that all mail packages do provide the same user way of defining aliases, even if they manage them differently after that. Yves.
Re: Pb: gdb cannot read core from 2.0.8 (is it a gdb or kernel problem)?
Miquel van Smoorenburg writes: You (Yves Arrouye) wrote: GDB 4.15.1 (i486-linux), Copyright 1995 Free Software Foundation, Inc... 0¨´ @/core: not in executable format: File format not recognized So there's a problem there. Do you have an idea about who is faulty? Gdb? As I understand it, the way you call gdb is gdb [executable] [its core file] preferrably with [executable] compiled with -g and linked statically I doubt that gdb can read core files without an accompanying executable.. You're right, sorry. It's gdb [otheropts] [prog[core|procID]] But the message is really misleading... It would ne nice if Gdb checked wether the prog arg was a core first, and in this case tell that's the case and remind usage. (Not that I ask that it does that: I should have read the manual page, of course.) Yves.
Re: Emacs per-package startup files
Mark Eichin writes (Re: Emacs per-package startup files): ... [it would make it easier to fix the /etc/passwd problem that mhpower mentioned], but in those cases we can't really change the database because of existing use, whereas with emacs we are free to do that.) Right, that was my line of thought exactly. ... Hmm. As for dpkg needing install-elisp, I'm not quite sure I buy that, because it would seem to argue that *any* install-* should be included in dpkg. Then again, there is only install-info which *is* in dpkg, and install-mime which is in mime-support which has it's own justification. There aren't any others... If anyone writes others I'll be happy to include them in dpkg, provided that they're GPL'd. ... So, do these files go in /var/lib/emacs, /etc/emacs, or /usr/lib/emacs/site-lisp, and why? I can set it up and send changes to the emacs package maintainers this weekend if that gets worked out... It needs to be in /etc, and the files must be conffiles, so that sysadmins can edit them and so forth. I suggested /etc/emacs/site-start.d because we already have one Emacs /etc file and /etc is already full of stuff. I guess the only thing unresolved is what directory to use, and what the little bit of elisp should look like that scans the directory. How about making /usr/lib/emacs/site-start.el a file rather than a symlink, and having it load /etc/emacs/site-start.el and run /etc/emacs/site-start.d. I'll look at the text explaining rc.d numbering to see what makes sense for that. (I guess in theory we need the ordering, but in practice, with autoload, do we need ordering here at all? certainly none of the existing packages need it. But I suppose picking an order at least makes debugging easier...) If you just sort the filenames before you run them you'll get the ordering for free, and if we say that people who don't know what number to use or don't think they have ordering constraints use 50 then if we do decide we want something loaded early we can do it. Ian.
Re: CC's on this mailing list
Miquel van Smoorenburg writes (Re: CC's on this mailing list): ... I've noticed on some other lists that everything that is posted on the list has From: set to the original sender, Reply-To: to the list address and Cc: deleted. This is actually very nice. Would it be hard (or just a bad idea) to put this in the debian list server? This makes it hard in some mailers to reply to just the poster. Ian.
Releases other than by the package maintainer
There are a couple of circumstances when a new version of a package needs to be released by someone other than the usual maintainer: * Architecture-specific patches which need to be integrated. * Maintainer is away or can't do it for some other reason. * Urgent security and other fixes. I propose that we should mandate: (a) a broad description of when you should and when you shouldn't do this, and how not to tread on the usual maintainer's toes. (b) that the non-usual-maintainer releases should use a particular revision format: eg, hello-1.3-8 would become hello-1.3-8.1. Ian.
Re: Emacs per-package startup files
Hmm. As for dpkg needing install-elisp, I'm not quite sure I buy that, because it would seem to argue that *any* install-* should be included in dpkg. Then again, there is only install-info which *is* in dpkg, and install-mime which is in mime-support which has it's own justification. There aren't any others... I agree that install-elisp should be the responsibility of emacs. Packages that want to use it should put an if [ -x /sbin/install-elisp ] then [...] fi around the install/uninstall code. This will allow packages to take advantage of it if available, but not actually depend on emacs being installed. This is the line I've taken with mime-support. There is a disadvantage that installing emacs after installing a package (p) that tries to call install-elisp will mean that p is completely unknown to emacs until p is either reinstalled or upgraded. I personally don't see this as a problem as upgrades happen fairly regularly. Of course, the above problem only exists if install-elisp does some setup work, as install-mime does. So, do these files go in /var/lib/emacs, /etc/emacs, or /usr/lib/emacs/site-lisp, and why? I can set it up and send changes to the emacs package maintainers this weekend if that gets worked out... I'd vote for /usr/lib/emacs/site-lisp. Why? Because /var/lib/emacs is for files that can't be on a read-only filesystem and /etc/emacs is for user config files and the like. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: CC's on this mailing list
I'm considering adding a paragraph to the policy manual telling people not to CC each other when replying to messages on debian-devel. Is it the consensus of the list that this would be a good idea ? It's a difficult call. Quite often I get copies of mail simply because I posted the msg being replied to, even though it is only relavent to the group and not me specifically. If it is relavent to me specifically (eg. relates to one of my packages), then I like being copied because it means I won't miss it in the volume of the list. The best solution I can think of would be a daemon that monitors the lists and if it sees an outgoing message that was copied to someone else, it sends a very polite email saying that the user should be sure to copy the original author _only_ if it specifically relates to him/her. Making sure that such a notice doesn't get mailed to a user more than once a month would also be a good idea. It's more work, but I think it would have the best results in the end. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Conversion procedure for new source packages DRAFT
This is my first draft of a quick document saying how to convert an
old to a new source package.
DO NOT DO ANYTHING YET except read this and suggest amendments.
Ian.
* Download the original source code from wherever it can be found and
do any rearrangement required to make it look like the original tree
of the Debian source. Put it in package-upstream-version.orig/.
* Rename all files debian.* to debian/*. There may be some exceptions
to this, but this is a good start.
* Edit the debian/changelog - create or rename it if necessary. Add a
new revision to the top with the appropriate details.
* Edit/create debian/control:
+ Remove the Version field. If it is generated unusually (not equal
to the source version) you must use the -v option to
dpkg-gencontrol (see below). Section, Priority, Maintainer go
above the line, most of the rest below.
+ Reorder the fields and add a blank line at an appropriate point,
separating the source package fields from the binary package
fields.
+ Add the Source field.
+ Add the Standards-Version field.
+ Change the Architecture field for each package to `any', `all' or
whatever. If there isn't an Architecture field add one.
+ If any other seddery or things used to happen to make the binary
control files use dpkg-gencontrol's variable substitution features
to achieve the same effect. Use debian/substvars if you need to
put unusally-generated information (apart from details of .deb
files) in the .changes file too.
* Edit the debian/rules:
+ Remove the source and diff and any changes and dist targets. These
things now happen in a package-independent way and are not done by
debian/rules.
+ Change the binary target to use dpkg-gencontrol to make the package
control file(s).
+ Change occurrences of debian-tmp to debian/tmp.
+ Change occurrences of debian.{post,pre}{inst,rm} to debian/*.
+ Remove the version number make variable if there is one.
* Check that the debian/README is really the copyright file, and if so
rename it to debian/copyright and edit debian/rules accordingly. If
it isn't then find debian/copyright and decide what to do with the
README.
* Check for various other anachronisms:
+ Remove any Package_Revision, Package-Revision or Revision fields.
+ Rename Optional to Suggests, Recommended to Recommends.
+ Change /usr/doc/examples/package to /usr/doc/package/examples
and /usr/doc/copyright/package to /usr/doc/package/copyright.
* Look everything over.
* Do a test build using dpkg-buildpackage -ur -uc -rwhatever. Check
the permissions and locations of the results, and that the source
build happened OK. Test install the binary package(s) and test
extract the source package(s).
* Sign the release: either re-run dpkg-buildpackage (this will rebuild
the package entirely), or PGP-sign the .dsc, rebuild the .changes
using dpkg-genchanges, and then PGP-sign the .changes.
--
Ian Jackson, at home. [EMAIL PROTECTED] + 44 1223 3 31579
General: [EMAIL PROTECTED]Permanent: [EMAIL PROTECTED]
Churchill College, Cambridge, CB3 0DS. http://www.cl.cam.ac.uk/users/iwj10/
Re: New package standards - LAST CALL
Miquel van Smoorenburg writes (Re: New package standards - LAST CALL): ... I also think that when you make the new source package official, we should warn all maintainers of the base packages and ask them to convert their packages to the new standard. If they don't react in say 2 weeks, someone else can do it (I'll take some) like David did during the transition from a.out to ELF. Yes. If a few people do a lot of packages it's probably quicker and less error-prone, anyway, then having the maintainers do it themselves. On the other hand having the maintainers do it themselves will get them to learn the ropes ... ... Well, one other idea. Since the original source and the patch are kept in the archive, would it be possible to look for an additional architecture dependant patch? [...] No. Any architecture dependencies should be avoided; if they can't they should be dealt with at build-time in the package itself, rather than by making several versions of the package. [..] It would be a tremendous advantage when porting to a new architecture - the porter need only supply the extra patch to the debian archive and it will just work. Also, the patch will be in a public place so that the original maintainer can integrate the patch in the next version of the package. The porter should make an architecture-independent patch (ie, one that will work on any architecture) and then either: (a) add `.1' to the Debian revision and release a new source package with their binaries - they should send the patch to the original maintainer for inclusion, too; or (a) send the patch to the main maintainer (or to [EMAIL PROTECTED]) and wait for it to be included. Ian.
Re: Name clash in prospective package
Lars Wirzenius writes (Re: Name clash in prospective package ): Ian Jackson: The point of not putting things in /usr/local isn't, as I see it, so Well, I'm not in full agreement, but it's not important enough. Fair enough. I propose the following resolution: I can live with the what you propose. Good. I've added the section below. Ian. sect1tt/usr/local/ - for the use of the system administrator p As mandated by the FSSTND no package should place any files in tt/usr/local/, either by putting them in the filesystem archive to be unpacked by prgn/dpkg/ or by manipulating them in their maintainer scripts. p Every package that searches a number of directories or files for something (for example, looking for shared libraries in tt/lib/ or tt/usr/lib/) should search an appropriate directory in tt/usr/local/ too. p In order that the system administrator may know where to place additional files a package should create an empty directory in the appropriate place in tt/usr/local/ by supplying it in the filesystem archive for unpacking by prgn/dpkg/. The tt/usr/local/ directory itself and all the subdirectories created by the package should have permissions 2775 (group-writeable and set-group-id) and be owned by tt/root.staff/. p In the future it will be possible to tell prgn/dpkg/ not to unpack files matching certain patterns, so that system administrators who do not wish these directories in tt/usr/local/ do not need to have them.
Re: Qmail, smail and sendmail
Yves Arrouye writes (Re: Qmail, smail and sendmail): ... That's what I do. I even run sendmail -bi if newaliases is not found. But I wanted to be sure that all mail packages do provide the same user way of defining aliases, even if they manage them differently after that. I'll specify in the mail processing section of the polcy manual: tt/etc/aliases/ is the source file for the system mail aliases (e.g. postmaster, usenet, etc.) - it is the one which the sysadmin and postinst scripts may edit. After tt/etc/aliases/ is edited the program or human editing it must call prgn/newaliases/. All MTA packages should come with a prgn/newaliases/ program, even if it does nothing, but older MTA packages do not do this so programs should not fail if prgn/newaliases/ cannot be found. p Ian.
Re: CC's on this mailing list
Yves Arrouye writes (CC's on this mailing list): Ian Jackson writes: I'm considering adding a paragraph to the policy manual telling people not to CC each other when replying to messages on debian-devel. Is it the consensus of the list that this would be a good idea ? It would be nice also to not have long messages fully quoted :-( Right, this is going into the policy manual. Ian.
Re: Pb: gdb cannot read core from 2.0.8 (is it a gdb or kernel problem)?
Yves Arrouye writes (Re: Pb: gdb cannot read core from 2.0.8 (is it a gdb or kernel problem)?): ... But the message is really misleading... It would ne nice if Gdb checked wether the prog arg was a core first, and in this case tell that's the case and remind usage. (Not that I ask that it does that: I should have read the manual page, of course.) You might also see my bug report, #3515. Ian.
Bug#4093: start-stop-daemon fails to kill process
Yves Arrouye writes (Bug#4093: start-stop-daemon fails to kill process): Maybe should it kill the process whose pid is in the pidfile, even if it does not think the executable is running? Here is an example of the problem: marin66# /etc/init.d/apache stop no /usr/sbin/apache found; none killed. marin67# cat /var/run/apache/apache.pid 12707 marin68# ps -ax|grep 12707 12707 ? S0:00 /usr/sbin/apache 20378 p9 S0:00 grep 12707 Are you using a new apache package ? On my system apache installs itself as /usr/sbin/apache-httpd. In any case, could you check to see what ls -ali /proc/12707/exe ls -aliL /proc/12707/exe shows and what ls -ali /usr/sbin/apache shows ? Thanks, Ian.
Re: Documentation formats
Rob Browning writes: Lars Wirzenius [EMAIL PROTECTED] writes: I don't think we have free software packaged to do full text searches. We have glimpse and ferret, neither of which is free. There's something that is part of freeWais, but I haven't looked at it yet. Someone with the time should find and package one. It should be usable from the command line so that it can easily be integrated into Debiandoc. It'd be nice to have something like altavista, that could generate a page containing a (heirarchical) list of the references found. The search program ht://Dig (which has an admittedly odd name) comes with the GNU general public license. Its home page is: http://htdig.sdsu.edu/ Also, there's been a Javascript on comp.infosystems.www.authoring.cgi that uses the Altavista search engine to search only your own site. (Seems like exploiting rather than excluding robots.) Regards, Susan Kleinmann
Bug#4097: smail cron jobs don't test if smail is installed
-BEGIN PGP SIGNED MESSAGE- After removing smail, cron keeps trying and failing to execute /usr/lib/smail/checkerr every day out of /etc/cron.daily/smail that does not exist anymore. Proposed fix: check for existence of /etc/cron.daily/smail before running. - -- Alexander Goldstein email: [EMAIL PROTECTED] Finger [EMAIL PROTECTED] for PGP key. -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBMgzr63DgMe9hQbElAQFiHQP/V5B0HaLuMtZ6SgRSFPrfQBsfRkbol89P dk10W5uorwfCMmPxOAGak/4iiOfJpHubsTxrWhHKBvkLkf2Pb63A5cHpl5MDsWyK eTAzB954myfrXsPvnG7r+ld0DGjbRWI1ZY5GxH8L2NcD1/JLE3x460mfm/39xHP0 R7tRgG/7CGc= =eWmX -END PGP SIGNATURE-
search engines
[ I sent this to Lars, but then thought perhaps the whole list might be interested. Sorry for the duplicate mail, Lars! ] Lars Wirzenius [EMAIL PROTECTED] writes: I don't think we have free software packaged to do full text searches. We have glimpse and ferret, neither of which is free. There's something that is part of freeWais, but I haven't looked at it yet. Someone with the time should find and package one. It should be usable from the command line so that it can easily be integrated into Debiandoc. It'd be nice to have something like altavista, that could generate a page containing a (heirarchical) list of the references found. I've been thinking about what you said regarding search engines for debiandoc. As I understand it, this is to be a debian package, is it not? Debian has been a great help in my company and we'd like to give something back, so how about this... We'll make a version of Ferret that you can include and redistribute with your package completely freely. It will be, however, a query-only version. We'd then licence to you (free, of course) a full version from which you could generate the index that went in the package. What do you think of this idea? An alternative would be to have your package depend on the evaluation version of ferret that exists in the distribution, but I don't think this is a good idea. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#4096: abuse is still a.out
Package: abuse Version: 1.10-4 abuse is still a.out [EMAIL PROTECTED]:~$ file /usr/games/lib/abuse-1.10/abuse.x11R6 /usr/games/lib/abuse-1.10/abuse.x11R6: setgid Linux/i386 demand-paged executable (ZMAGIC), stripped Regards, Andreas
