fvwm{,2,-common} packages up for adoption
Hi, I am (in theory) still maintaining the following packages: fvwm fvwm2 fvwm-common xloadimage xcal In practice, I haven't uploaded new versions of these for many months. Both xcal and xloadimage have few outstanding bugs. fvwm2 has many outstanding bugs, some of which are in reality either feature requests or disagreements with particular configuration details. With the recent move of fvwm2 development into CVS, the release rate has increased greatly (however, it's also likely the stability has decreased somewhat). This is one of the reasons I haven't made any 2.1.x releases of fvwm2. But its mainly due to lack of time. Therefore, I'd like to give away my fvwm packages, ie fvwm, fvwm2 and fvwm-common. I'm happy keeping xloadimage and xcal, but I think it would be much better to have someone else look after the fvwm stuff. Volunteers should mail me ([EMAIL PROTECTED]), and we can organise an orderly handover. Oh, and it would help greatly if the crap on debian-private were to be kept to the minimum - political rants can happen quite happily in the pubic for all to see. Austin PS: I am not subscribed to this list
acct and 2.1.96
On Mon, 27 Apr 1998, Thomas Gebhardt wrote: Hi Austin, Incidentally, simply rebuilding the acct package against the new header files is a little tricky, since the ./configure script uses sys/acct.h in preference to linux/acct.h Did you manage to build a acct package for 2.1.96? If so, could I get it from you? I did in the end. I'm not sure what the best way of releasing it is, however. My version has exactly the same version number as the original I built it from. I'll put it up at: http://www.cl.cam.ac.uk/~and1000/acct_6.3.2-2_i386.deb for a few weeks, but I'll only be able to get it there sometime tomorrow. Austin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
acct: process accounting and 2.1.96
The latest development linux kernels have a fairly substantially changed struct acct defined in acct.h. Currently: libc5: sys/acct.h just includes linux/acct.h (2.0.32 version) libc6: sys/acct.h is a new file, but it defines a structure which happens to be the same as linux/acct.h (2.0.32 version). With 2.1.xx, linux/acct.h changes incompatibly - the structure is larger, the command name comes at the end (not the start), and there are some additional fields. The question is then how do we migrate to the new format? Incidentally, simply rebuilding the acct package against the new header files is a little tricky, since the ./configure script uses sys/acct.h in preference to linux/acct.h Austin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anyone want to make a Debian XDM login screen?
Wichert Akkerman [EMAIL PROTECTED] writes:
Previously Brian Mays wrote:
There is an easy way to get this button on your screen, assuming that you
have the TCL/TK packages installed.
I've done the same thing (using Motif), but added a confirmation check..
I've found that when I move the mouse or press a mousebutton when the
screen is in powersaving can have very disconcerting effects with a
reset-button out there..
I did something similar for my ancient Slackware 1.2 box.
My solution was a trivial Xt button called XShutdown. It includes a
confirmation stage, and calls shutdown itself (sorting out a console
for it's output while it's at it).
It should be check it works with ELF, latest X libraries, the current
sysvinit, but I don't anticipate any probplems.
Austin
/* Copyright (c) Austin Donnelly 1995-1998
* [EMAIL PROTECTED]
*
* This software is released under the GPL. It comes with NO WARRANTY.
*
* xshutdown.c
*
*/
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/types.h
#include fcntl.h
#include errno.h
#include string.h
#include X11/Intrinsic.h
#include X11/StringDefs.h
#include X11/Shell.h
#include X11/Xaw/Command.h
#include X11/Xaw/Box.h
#include X11/Xaw/Dialog.h
/* globals */
char *progname;
Widget pshell, topLev;
/* prototypes */
void Shutdown_btn(Widget, XtPointer, XtPointer);
void Ok_btn(Widget, XtPointer, XtPointer);
void Cancel_btn(Widget, XtPointer, XtPointer);
void start_shutdown(void);
void popdown(Widget);
void die(const char *);
int main(int argc, char **argv)
{
XtAppContext app;
Widget box, shutdown, dialog, ok, cancel;
/* make the widget hierarchy */
topLev = XtVaAppInitialize(app,
XShutdown,
NULL, 0, /* no cmd line options */
argc, argv,
NULL,/* app-defaults */
NULL); /* end of args */
box = XtVaCreateManagedWidget(
box, /* name */
boxWidgetClass,
topLev, /* parent */
NULL);
shutdown = XtVaCreateManagedWidget(
Shutdown,
commandWidgetClass,
box,
NULL);
/* now make the popup hierarchy */
pshell = XtVaCreatePopupShell(pshell,
transientShellWidgetClass,
topLev,
NULL);
dialog = XtVaCreateManagedWidget(
dialog,
dialogWidgetClass,
pshell,
NULL);
ok = XtVaCreateManagedWidget(
ok,
commandWidgetClass,
dialog,
NULL);
cancel = XtVaCreateManagedWidget(
cancel,
commandWidgetClass,
dialog,
NULL);
/* callbacks */
XtAddCallback(shutdown, XtNcallback, Shutdown_btn, 0);
XtAddCallback(ok, XtNcallback, Ok_btn, shutdown);
XtAddCallback(cancel, XtNcallback, Cancel_btn, shutdown);
/* customisation */
XtVaSetValues(dialog,
XtNlabel, Really shutdown?,
NULL);
progname = argv[0];
/* main code */
if (argc!=1)
{
printf(Usage: %s\n, progname);
printf(\tRun as root, when button clicked, does a shutdown(8)\n);
exit(1);
}
/* draw the things */
XtRealizeWidget(topLev);
XtAppMainLoop(app);
return 0;
}
void Shutdown_btn(Widget shutdown, XtPointer client_data, XtPointer call_data)
{
Position x, y;
Dimension width, height;
/* configure bits n bobs */
XtVaGetValues(topLev,
XtNwidth, width,
XtNheight, height,
NULL);
XtTranslateCoords(topLev,
(Position) width / 2,
(Position) height + 10,
x, y);
XtVaSetValues(pshell,
XtNx, x,
XtNy, y,
NULL);
XtSetSensitive(shutdown, FALSE);
/* show popup */
XtPopup(pshell, XtGrabNonexclusive);
}
void Ok_btn(Widget w, XtPointer client_data, XtPointer call_data)
{
popdown((Widget) client_data); /* popdown resensitize shutdown */
start_shutdown(); /* fork off shutdown(8) */
}
void Cancel_btn(Widget w, XtPointer client_data, XtPointer call_data)
{
popdown((Widget) client_data); /* popdown resensitize shutdown */
}
void popdown(Widget show)
{
XtPopdown(pshell);
XtSetSensitive(show, TRUE);
}
/* this code is enough to safely shutdown the machine */
void start_shutdown(void)
{
pid_t pid;
int infd
Bug#4289: mount's swapon command doesn't have the -s option
Package: mount Version: 2.5j-1.1 In many traditional unices, swapon can take a -s option. This means list the partition (or files) currently in use. Linux's swapon doesn't have this option, but it would be nice if it did. I don't think this information is made available outside the kernel; perhaps it should be a file in /proc? (This bug should probably be forwarded upstream.) Austin
Bug#4082: No documentation for fvwm modules
On Thu, 8 Aug 1996, Larry Gilbert wrote: Package: fvwm Version: 1.24r-24 Documentation for the fvwm modules appears to be missing from this package. Yes, that's because although the manpages have changed a little between the two versions of fvwm, they still have the same names. This means you can only have one set of manual pages installed. [Insert obligatory renewal of the fvwm-package-relying-on-fvwm2-package debate here.] :-) I have a new version of fvwm2 in preparation, it should be released by the end of the month. This introduces an fvwm-common package which will hopefully silence the debate once and for all :) I only noticed this because I tried to look up information on GoodStuff. This module appears to be available only in the fvwm package, and consequently there is no corresponding documentation in the fvwm2 package. (There appears to be an otherwise full complement of Fvwm* man pages in the fvwm2 package.) Thanks for pointing this out: I'd forgotten about the GoodStuff manpage. I will include it in the fvwm package that I'll release at the same time as the new fvwm2 one. In the meantime, I'll leave this bug report outstanding, to remind me to do this. Austin
fixed: ange-ftp doesn't set TERM=dumb in inner shell
I send off a bug report against emacs to the emacs maintainers, and
got a patch back.
Here's my report, and the patch, delimited by =-=-=-=-= lines
Austin
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From: [EMAIL PROTECTED] (Austin Donnelly)
Newsgroups: gnu.emacs.bug
Subject: ange-ftp doesn't set TERM=dumb in inner shell
Date: 6 Dec 1995 07:39:47 -0500
Lines: 71
Message-ID: [EMAIL PROTECTED]
In GNU Emacs 19.29.1 (i486-debian-linuxaout, X toolkit) of Wed Sep 20
1995 on imagine configured using --prefix=/usr --with-pop=yes
--with-x=yes --with-x-toolkit=lucid i486-debian-linuxaout
The standard Debian /usr/bin/ftp has readline support, which is very
nice. However, this means that it outputs control codes to make full
use of the terminal.
The problem is that ange-ftp can't parse the ftp output when it has
all these control sequences in it.
/usr/bin/ftp will keep quiet if TERM is set to dumb, but as things
stand, it believes TERM to be xterm, so it outputs turn keypad on
and turn keypad off codes when giving prompts.
This means that emacs running (with -nw) out of an xterm, or running
in X fully can't do ange-ftp. Starting emacs by typing:
bash$ TERM=dumb emacs
solves the problem. However, this isn't a long-term solution.
I think the best solution would be to start the ftp client in an
environment where TERM=dumb.
I include the error messages from ange-ftp for completeness below:
(Note that both these buffers contain ESC control characters. I have
also provided uuencoded copies of them in case they get mangled in transit).
--- buffer: *ftp [EMAIL PROTECTED] -
[?1h=open src.doc.ic.ac.uk
ftp [?1lConnected to phoenix.doc.ic.ac.uk.
220 sunsite.doc.ic.ac.uk FTP server (Version wu-2.4(23) Sun Jul 9 23:09:29 BST
1995) ready.
Remote system type is UNIX.
Using binary mode to transfer files.
[?1h=ftp
begin 644 ftp-buffer
MUL_,6@;/6]P96X@W)C+F1O8RYI8RYA8RYU:PIF='`^(!M;/S%LSY#;VYN
[EMAIL PROTECTED]\@AO96YIYD;V,N:6,N86,N=6LNC(R,!S=6YS:71E+F1O
M8RYI8RYA8RYU:R!5%`@V5R=F5R(A697)S:6]N('=U+3(N-@R,[EMAIL PROTECTED]
M($IU;`Y(#(S.C`Y.C(Y($)35`Q.3DU*2!R96%D2X*4F5M;W1E('-YW1E
M;2!T7!E(ES([EMAIL PROTECTED]E5S:6YG()I;F%R2!M;V1E('1O('1R86YS9F5R
5(9I;[EMAIL PROTECTED];6S\Q:!L]9G1P/B`*
`
end
-- buffer: *Messages* --
Loading ange-ftp...
Loading ange-ftp...done
Opening FTP connection to src.doc.ic.ac.uk...
FTP Error: OPEN request failed: [?1lConnected to phoenix.doc.ic.ac.uk.
begin 644 message-buffer
M3]A9EN9R!A;F=E+69T[EMAIL PROTECTED],;V%D:6YG(%N9V4M9G1P+BXN9]N90I/
M5N:6YG($944!C;VYN96-T:6]N('1O('-R8RYD;V,N:6,N86,N=6LN+BX*
M1E10($5RF]R.B!/4$5.(')E75E[EMAIL PROTECTED];5D.B`;6S\Q;!L^0V]N;F5C
==5D('1O('!H;V5N:[EMAIL PROTECTED][EMAIL PROTECTED]
`
end
Thanks,
Austin
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Date: Thu, 7 Dec 1995 01:18:18 -0500
From: Richard Stallman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: ange-ftp doesn't set TERM=dumb in inner shell
Thanks. Does this fix it?
cd ~/e19/lisp/
diff -c /rms/e19/lisp/ange-ftp.el.\~1\~ /rms/e19/lisp/ange-ftp.el
*** /rms/e19/lisp/ange-ftp.el.~1~ Thu Nov 16 17:27:14 1995
--- /rms/e19/lisp/ange-ftp.el Wed Dec 6 18:28:40 1995
***
*** 1778,1784
;; It would be nice to make process-connection-type nil,
;; but that doesn't work: ftp never responds.
;; Can anyone find a fix for that?
! (let ((process-connection-type t))
(if use-gateway
(if ange-ftp-gateway-program-interactive
(setq proc (ange-ftp-gwp-start host user name args))
--- 1778,1787
;; It would be nice to make process-connection-type nil,
;; but that doesn't work: ftp never responds.
;; Can anyone find a fix for that?
! (let ((process-connection-type t)
! (process-environment process-environment))
! ;; This tells GNU ftp not to output any fancy escape sequences.
! (setenv TERM dumb)
(if use-gateway
(if ange-ftp-gateway-program-interactive
(setq proc (ange-ftp-gwp-start host user name args))
Diff exited abnormally with code 1 at Wed Dec 6 18:48:56
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The diff in fact works fine.
Could the emacs maintainer (Ian M) include this in the next emacs
release, please ? (I think that version 19.30 is out).
Alternatively, does Ian M want to give the emacs and emacs-el
packages to me ?
Austin
Bug#1933: w from procps gives wrong idle times
Package: procps Version: 0.97-4 valour$ w 5:07pm up 15 days, 20:31, 7 users, load average: 0.16, 0.11, 0.09, 3/76 User tty login@ idle JCPU PCPU what and1000 ttyp0 4:15pm49 24 -bash (bash) and1000 ttyp1 4:15pm30 2 bash jbk1000 ttyp4 4:41pm11 2:12 58 xpilot mphhpd.ph.man.ac.uk ijackson ttyp5 5:04pm22/bin/bash ajm46ttyp6 4:45pm 2:10-bash (bash) ajm46ttyp7 4:45pm3 2 rlogin chiark.chu ajm46ttyp8 4:45pm18 1 1 rlogin thor valour$ date Fri Dec 1 17:07:31 GMT 1995 Notice that: (1) ijackson logged in at 5.04pm, but is allegedly idling 22 mins - this is clearly impossible, since it's now 5.07pm! (2) the same thing is true of ajm46, on ttyp6. This is a reasonably reproducable situation. The idle time is wrong from the appearance of the xterm, and is correct once something has been typed at it. Could the maintainer please have a look at how idle times are calculated ? [I suspect that the idle time is taken as the atime on the /dev/ttyp?? devices, but maybe they're not being updated during the login sequence, so that the idle time is really the time since that tty was last used. Of course, as soon as the user uses the shell, the idle time is correct.] Austin
Bug#1513: bin/kill segfaults if invoked instead of killall
Package: bsdutils Version: 1.3-1 chiark:~ /bin/kill -HUP syslogd Segmentation fault (core dumped) chiark:~ [...core dump snipped...] There were a number of bugs in /bin/kill, most due to the poor code quality making loops difficult to decipher. A large number of signals were missing from the signal list, and a variety of out-by-one errors were liberally sprinkled around :) This is fixed in bsdutils-1.4-1, out now. Austin
Bug#1764: bin/kill segfaults
On Wed, 25 Oct 1995 15:40:09 +1000 (EST), Herbert Xu [EMAIL PROTECTED] wrote: Package: bsdutils Version: 1.3-1 It is trivial to make /bin/kill segfault: $ /bin/kill -l INT QUIT ILL TRAP ABRT UNUSED FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT CHLD Segmentation fault (core dumped) The appended patch fixes the bug. I suspect the person who wrote the code has had some bad memories about Pascal :) PS NSIG is the largest valid signal number + 1. [...patch snipped...] The appended patch was very helpful, thanks. A new kill, hopefully with the bugs fixed, is in bsdutuils-1.4-1, which I am about to upload to the uk upload site. Austin
Bug#1897: apropos not resilient to index.db corruption
Package: man
Version: 2.3.10-2
'man -k' and 'apropos' with a damaged or corrupted index.db
segfaults. This is not a very friendly error message.
I have traced the problem to the following piece of code:
whatis.c
364: /* scan for the page, print any matches */
365: static int apropos(char *page, char *lowpage)
366: {
367:datum key, cont;
368:int found = 0;
369:
370: #ifndef BTREE
371:datum nextkey;
372:
373:key = MYDBM_FIRSTKEY(dbf);
374:while (key.dptr) {
375:if (*key.dptr != '$') {
376:cont= MYDBM_FETCH(dbf, key);
377: #else /* BTREE */
378:int end;
379:
380:end = btree_nextkeydata(dbf, key, cont);
381:while (!end) {
382:if (*key.dptr != '$') {
383: #endif /* !BTREE */
384:if (*cont.dptr != '\t') { /* a real page */
--
If the database is corrupted, then it is possible to read off the end
of the database without seeing a '$' (line 375), and calling
MYDBM_FETCH() when there isn't any data to fetch. This makes 'cont'
NULL (line 376), which gets dereferenced in line 384. Kaboom,
segfault.
Could this infelicity be passed on to the upstream maintainer, please
?
The problem with just checking for null is that this is very likely
not the only place where things can go wrong.
Also, it might be nice to have a database consistancy checker, that
would tell you if a given database were consistant.
Austin
Bug#1897: apropos not resilient to index.db corruption
On Sat, 25 Nov 1995, Alvar Bray wrote: [...] I have heard several other people say they have had corrupt database files - how do they get corrupted? I have never managed to corrupt mine (but then I, as the package maintainer, wouldnt would I) I have no idea how mine got corrupted, sorry :( Austin
Bug#1855: packages adding entries to /etc/group
Package: base Version: 0.93.6-13 This package creates some new groups: floppy, tape, games However, it does this by having a new /etc/group file. This causes a conflict in the configuration files, and people have to manually edit their /etc/group file. In my opinion, adding groups or users should be done by a script, not by a new file. Austin
Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance preparation for a.out abolishment)
In article [EMAIL PROTECTED], Bill Mitchell [EMAIL PROTECTED] wrote: [...] However, more directly to the point of moving elfward, I like Ian's suggestion about a elf-available(8) test during preinst of elf-dependent (elfish?) packages. It seems clean, simple, and effective to me. And if the script were called 'elf-system', then the standard error message would be quite convenient: elf-system: not found :) Austin
fvwm version 2
In the reasonably near future fvwm version 2 will be released (ie, within the next few weeks, I am told). fvwm 2 has a radically different ~/.fvwmrc format, such that everyone will need to modify theirs before being able to even use fvwm2. The fvwm2 distribution will come with a shell script that does a simple-minded conversion from your old ~/.fvwmrc to the new style. Recognising the difficulty in moving over, the default way of building fvwm results in an fvwm2 binary, and the new rc file as ~/.fvwm2rc. The system-wide directory is also differently named. This is in a bid to make the new old versions co-exist happily. I'd like people's opinions: should I package up fvwm2 as 'just an upgrade' to the fvwm package - or should I make it a _new_ package, fvwm2, allowing both to co-exist on a Debian system ? Personally, I think a new package is the way to go. Comments ? Austin
Bug#1770: xntp dumps core with kernel 1.3.35
Package: xntp Version: 3.4x-1 The 'struct timex' structure has changed in the newser 1.3.x kernels (for x approx 28 or so, I'm told). This means that xntpd binaries compiled agains old kernels dumps core on startup. I'm told that version 3.4t has support for the latest linux, but I haven't tried it. Also, there is the problem that there would need to be _2_ xntp packages, one for old kernels, one for new kernels. Eugh!! Can anyone think of a better idea ? Austin
Bug#1726: permissions on svgalib utilities
Package: svgalib Version: 1.25-4 The following programs are installed setuid root: restoretextmode restorefont restorepalette dumpreg fix132x43 This allows any user to completely hose the console at will. Can I suggest that they be made: -rwsr-x--- 1 root console (this requires a new group, console, to be created). Austin
Bug#1684: fvwm creates /tmp/fvwmrcXXXX - fixed: patch included
I've had a look at this bug: its some pretty dire code in the section
the reads your .fvwmrc.
I submit the following patch to fix the problem.
Austin
--- configure.c.old Fri Oct 20 16:48:44 1995
+++ configure.c Fri Oct 20 21:36:12 1995
@@ -1979,12 +1979,10 @@
/* Generate a temporary filename. Honor the TMPDIR environment variable,
if set. Hope nobody deletes this file! */
-if ((vc=getenv(TMPDIR))) {
- strcpy(tmp_name, vc);
-} else {
- strcpy(tmp_name, /tmp);
+if ((vc=getenv(TMPDIR)) == NULL) {
+ vc = /tmp;
}
-strcat(tmp_name, /fvwmrcX);
+sprintf(tmp_name, %s/fvwmrc.%05d, vc, getpid());
mktemp(tmp_name);
if (*tmp_name == '\0')
Bug#1720: adduser: races, and chmod/chown - patch provided
Package: adduser
Version: 1.94-1
Three different bugs fixed here:
(1) There were a few race conditions in locking the password and
group files. A badly timed ^C could result in the lockfile
not being cleared.
(2) chown()/chmod() persistantly used in the wrong order throughout.
Could people please take note: chown()ing a file removes the
setuid and setgid bits on it! It's no use chmod()ing a file to
be setgid, then chown()ing it to someone else.
(3) The copy_to_file() routine doesn't preserve permissions. This
means that giving user's a default .xsession (which must be rwx)
isn't possible. I've modified copy_to_file() to now copy the
permissions with the file - but the files are chown()ed later, so
the setuid/setgid bit will be lost. (This is probably the right
thing to happen, in this instance).
As always, patch included...
Austin
--- /usr/sbin/adduser Thu Oct 5 20:02:18 1995
+++ adduser Sat Oct 21 02:24:19 1995
@@ -328,8 +328,8 @@
exit 1;
}
# lock the password file
-link $PASSWD, $PLOCK;
$passwd_state = locked;
+link $PASSWD, $PLOCK;
}
##
## check if the group file is locked, if necessary:
@@ -344,8 +344,8 @@
exit 1;
}
# lock the group file
-link $GROUP, $GLOCK;
$group_state = locked;
+link $GROUP, $GLOCK;
}
@@ -508,11 +508,11 @@
}
if ($make_group_also) {
- chmod (02775, $home_dir);
chown ($new_uid, $new_gid, $home_dir);
+ chmod (02775, $home_dir);
} else {
- chmod (0755, $home_dir);
chown ($new_uid, 0, $home_dir);
+ chmod (0755, $home_dir);
}
clean_up();
@@ -651,6 +651,7 @@
}
mkdir ($home_dir, $dir_mode);
chown ($new_uid, $new_gid, $home_dir);
+ chmod ($home_dir, $dir_mode); # since chown() resets set{gu}id bit
print done.\n if ($verbose);
##
@@ -857,12 +858,20 @@
##
sub copy_to_dir {
local ($file, $dir) = @_;
+local ($dev, $ino, $mode, $nlink, $uid, $gid, $rdev, $size,
+ $atime, $mtime, $ctime, $blksize, $blocks);
if ((! -f $file) || (! -d $dir)) {
return -1;
}
open (FILE, $file) || die open: $!;
+
+# grab access permissions for later
+($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,
+ $atime,$mtime,$ctime,$blksize,$blocks)
+ = stat($file);
+
$file =~ s+.*/++; # get the basename
open (NEWFILE, $dir/$file) || die open: $!;
@@ -872,6 +881,10 @@
close FILE;
close NEWFILE;
+
+# now copy permissions saved earlier. Note setuid/setgid bit destroyed
+# by a later chown call - maybe thats a good thing!
+chmod($mode, $dir/$file);
return 1;
}
