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
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* 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 c
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]
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]
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;
}
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#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
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#1801: tar manpage missing
I know the business of manpages for GNU software is a religious issue, but tar seems to be missing one. A number of different linux systems have manpages for GNU tar, although the tar package doesn't contain one as such. Could a manpage be maintained separately ? Austin
Bug#1832: Tar dumps core: film at 11
The command: tar -cvf backup:9Nov95.tar /home segfaults and dumps core without even beginning to write the archive. (I know tar is as buggy as hell, and I don't expect this one to get fixed, but it's nice to dream!) Austin
Bug#1844: md5sum has no manpage
Package: dpkg Version: 1.0.0 The dpkg package provides md5sum, but doesn't give any documentation for it. Austin
Bug#1845: dead.letter and dead.article are world readable
Package: trn Version: 3.6-2 Pnews with this version of trn creates dead.article world readable - however, the article may contain sensitive information. Similarly, dead.letter is also world readable. I haven't tracked down _exactly_ what creates it, but it seems likely that mail or mailx does. Austin
Bug#1856: creating perl header files
Package: perl Version: 5.001-6 While I wasa upgrading my perl package, I got: Setting up perl ... Creating Perl header files. This may take a while... /var/lib/dpkg/info/perl.postinst: /usr/local/include: No such file or directory /var/lib/dpkg/info/perl.postinst: /usr/local/include: No such file or directory Done. Shouldn't the script check for the existance of /usr/local/include before trying to read from it ? Maybe /usr/local/include should be created by the base discs. 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
Bug#1857: xarchie doesn't honour default archie server setting
Package: xarchie Version: 2.0.10-3 The file /etc/X11/xarchie/defaults #include's /etc/X11/xarchieR6/defaultserver, which doesn't exist, so the default server setting isn't honoured. 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#1545: write' can't write to telnet logins
On Wed, 4 Oct 95 15:06 BST, [EMAIL PROTECTED] (Ian Jackson) wrote: >Package: bsdutils? netstd? >Version: bsdutils 1.3-1, netstd 1.17-1 > >Are `mesg y' terminals on Debian supposed to be g+w, or go+w ? They are g+w. >telnetd (from netbase) and mesg (from bsdutils) seem to thing g+w >ought to be sufficient; however, write (also from bsdutils) seems to >require go+w (though `richard', who was writing to me in another >window at the time of the transcript below, didn't report that it >complained about his terminal being `mesg n'). > >Making write setgid tty may solve the problem, but such a decision >should only be taken after examining the code to make sure it's not a >security problem. write(1) had a number of bugs, most serious of which was attempting to write to terminals listed as dead in utmp. Making write(1) setgid tty is the right thing to do: I have carefully checked the source for possible holes, and have assured myself that there are none. I am closing this bug - it is fixed in bsdutils-1.4-1 As an aside, can I remind people that although I am fixing bugs in bsdutils, there still remains the problem with xterm's setting the permissions on /dev/tty to 622, owned . I have spoken to the new X11 maintainer, and its on his bug list. 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#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
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> [?1l>Connected 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
M&UL_,6@;/6]P96X@"YD;V,N:6,N86,N=6LN"C(R,"!S=6YS:71E+F1O
M8RYI8RYA8RYU:R!&5%`@2X*4F5M;W1E('-Y7!E(&ES([EMAIL PROTECTED]"E5S:6YG(&)I;F%R>2!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: [?1l>Connected to phoenix.doc.ic.ac.uk.
begin 644 message-buffer
M3&]A9&EN9R!A;F=E+69T<"[EMAIL PROTECTED],;V%D:6YG(&%N9V4M9G1P+BXN9&]N90I/
M<&5N:6YG($944"!C;VYN96-T:6]N('1O('-R8RYD;V,N:6,N86,N=6LN+BX*
M1E10($5R
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
Re: Bug#1978: man: default pager should be less
In article <[EMAIL PROTECTED]> you write:
>Austin Donnelly writes ("Bug#1978: man: default pager should be less"):
>> On Wed, 6 Dec 1995, Bill Mitchell wrote:
>> > less(1) isn't necessarily installed. more(1) is.
>>
>> Good point.
>
>Something ought to be done though, since more(1) can't be made to go
>backwards through manpages. This is rather a serious deficiency.
HP-UX's more(1) doesn't allow you to go back at all. Ever. :)
Austin
Re: Doubts building a new package...
On Mon, 17 Jun 1996, Rob Browning wrote: > [EMAIL PROTECTED] (Emilio Lopes) writes: > > > 2- The logo itself is a gif file. Is it non-free? I can convert it to > >a jpeg file if needed. > > Don't know about the other stuff, but for this I'd recommend png, not > jpeg. As I understand it gif's lossless, and so is png, and I think > png was meant to be the replacement for gif, so it'd be an appropriate > translation. That said, I've never messed with png myself, but I've > been planning to start using it when appropriate. I'm not convinced we need the package at all. After all, you get the image with the kernel sources anyway. 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
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
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
