Re: ChangeLog format
> I'd like for all members of the Project to agree on a common format. > Frankly, I don't like the one currently implemented in dchanges. I > assume there are a few people who agree with me, as not everyone is > using dchanges to write their announcements. Well, I haven't adopted any particular format since I don't want to invest any time in it until we have a standard. My only requirement is that if it contains things like file sizes and checksums, then there should be some machine assistance provided for generating it. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: ChangeLog format
On Sat, 21 Oct 1995, Ian Jackson wrote:
> Ian Murdock writes ("ChangeLog format"):
> > Personally, I like Ian J.'s ChangeLog format--I think it satifies
> > both goals of being human-readable and machine-readable.
>
> Would it be helpful if I wrote a spec. saying what the format is, so
> that people writing changelogs and programs to manipulate them had a
> document telling them what to do ?
Just to recap, from my point of view:
- There was an announcement that Bruce had taken over as the
main man driving the mechanics of the distribution.
- Bruce posted a new changelog format, and asked for discussion.
- There was a bit of discussion -- not much.
- Bruce asked for volunteers to produce a program to mechanize
changelog construction for package announcements.
- I volunteered, and the dchanges package resulted. It was
based on Bruce's posted format, with some minor points
clarified in email between Bruce and myself.
Perhaps I was mistaken in thinking the format had stabilized.
diff files in package uploads (was: Re: watch)
On Sat, 21 Oct 1995, Ian Murdock wrote: > [...] the only packages that > don't need a context diff are packages written specifically by the > Project for inclusion in the distribution, like dpkg.) I've been taking the requirement for .diff.gz files in package uploads as an absolute requirement. I complied with this requirement in the uploads I've done of packages written specifically for debian. In those cases, the .diff.gz file I uploaded was a compressed file containing a single '\n' char. That seemed reasonable to me -- avoiding a class of packages requiring special-case handling.
debian-devel@lists.debian.org
Package: minicom Version: 1.71-2 It's weird that minicom includes rz and sz and conflicts with package lrzsz. Wouldn't it be more nicer, if minicom depended on lrzsz and didn't include rz and sz?
Bug#1729: Naming of commands
Package: lrzsz Version: 0.11 Oops, after sending my last mail, I noticed another thing. The man pages of lrz and lsz speak about commands called rz, sz, rb, ..., but the actual binaries are named lsz, ... In my opinion, it would be better if the commands were also called traditionally rz, sz, ..., but if not, then, please modify the man-pages. Or keep the original commands, but make symlinks to the traditional commands (and man-pages).
Bug#1727: Man-pages
Package: lrzsz Version: 0.11 man lrz and man lsz produces several warnings and some garbage on the screen. It seems that the first two lines in lsz.1 and lrz.1, which are porpable supposed to be comments are invalid. The first three characters on those lines should be .\" rather than '\". After modifying them, they seem to work just fine.
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#1725: /etc/init.d/ppp still sources /etc/init.d/functions
Package: ppp Revision: 2.2-1 /etc/init.d/ppp still sources /etc/init.d/functions which, I believe, was decided to be a no-no, since start-stop-daemon subsumed all of its functionality, and since any script that uses it is effectively disabled from command-line use because /etc/init.d/functions chews up its command line options. Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Bug#1724: unexpected keypress translations
PACKAGE: xstd VERSION: 3.1.2-3 I noticed today that keypress translations are different in an xterm window than on a VC not running X. I'm really not sure if this is a bug or a case of "you should have expected that", but it caused a program expecting the VC-style keypress translations to misbehave when it got unexpected keypress translations in an xterm window. It seems to me that, unless there's some good reason otherwise, default keypress translations shouldn't change. To duplicate, type "cat -v", F1, ^D in a VC; observe the results; startx; and do the same thing in an xterm. I know that TERM=linux doesn't work right in an xterm and it's necessary to set TERM=xterm, but that's another issue (or at least I think it is). I'm no X-windows jock, as must be apparent by now. Just reporting unexpected behavior. [EMAIL PROTECTED] (Bill Mitchell)
Re: Debian Incoming
On Sat, 21 Oct 1995, Martin Schulze wrote: > upload ~ftp /debian/private/project/Incoming yes ftpadmin ftp 0600 dirs > Ahhh but not so easy :) Remember this doesn't use conventional ftpaccess files on this site. :) I will fix the problem though with something more like. upload imurdock.debian 0600 /debian.org/ftp/ /debian/private/project/Incoming Matt :)
Re: Mirror sites still having problems
On Sat, 21 Oct 1995, Ian Jackson wrote: > Several mirror sites are *still* in a mess, even after repeated > emails. > > At this point I think we can do one of two things: > > 1. Keep prodding them, phoning them up, &c &c &c &c - any > volunteers ? (If it comes to this I'll deal with > src.doc.ic.ac.uk.) src.doc.ic.ac.uk has been mirroring the current distribution for several days now. > 2. Move the whole of ftp.debian.org:/debian to /debian.real, and > replace with an empty /debian containing only `README.vanished'. > Leave for 3 days. Put it back. Only if we forwarn the current mirror sites to shut off their mirror alot of them have been working hard to get this especially the NON-US sites. Matthew S. Bailey [EMAIL PROTECTED]
Re: Mirror sites still having problems
Matthew Bailey writes ("Re: Mirror sites still having problems"):
> On Sat, 21 Oct 1995, Ian Jackson wrote:
>
> > Several mirror sites are *still* in a mess, even after repeated
> > emails.
> >
> > At this point I think we can do one of two things:
> >
> > 1. Keep prodding them, phoning them up, &c &c &c &c - any
> > volunteers ? (If it comes to this I'll deal with
> > src.doc.ic.ac.uk.)
> src.doc.ic.ac.uk has been mirroring the current distribution for several
> days now.
It's still broken. See transcript below. Many sites seem still to
have a `binary' directory at the top level, and have a symlink inside
debian-0.93 named binary pointing back to it. This seems to make the
standard mirror software fetch things with one hand and delete them
with the other.
> > 2. Move the whole of ftp.debian.org:/debian to /debian.real, and
> > replace with an empty /debian containing only `README.vanished'.
> > Leave for 3 days. Put it back.
>
> Only if we forwarn the current mirror sites to shut off their mirror alot
> of them have been working hard to get this especially the NON-US sites.
If you think there's a better way of doing things, such as contacting
sites individually, then let's do that.
It's just that some sites don't seem to be terribly responsive, and
these problems are getting rather old.
Ian.
-chiark:~> ncftp
NcFTP 2.1.0 (July 15, 1995), by Mike Gleason, NCEMRSoft.
Current local directory is /u/ian/download.
NcFTP> o src
Trying to connect to src.doc.ic.ac.uk...
The Archive -- SunSITE Northern Europe
SunSITE Northern Europe is located at the Department of Computing,
Imperial College, London and is running on a SPARCserver 1000 (with
7 CPUs and 42 GB of disk space) kindly donated by Sun Microsystems.
Local time is Sat Oct 21 19:30:33 1995, you are user number 61 (max 200)
Please read the README files for more information (e.g. what a .gz file
is, extensions to ftp, etc). Note that if ftp hangs or dies, try
putting a hyphen at the start of your password. Another useful feature
is the ls -sf:package command which does a quick scan of The
Archive looking for something called 'package'. Finally please note
that *ALL* transfers are logged and any misuse will be acted upon.
DISCLAIMER: Neither Imperial College nor Sun Microsystems are liable
for any use, storage or transmission of any files stored on this
archive.
Please email suggestions and questions to [EMAIL PROTECTED]
NOTE::
:: PLEASE use hostname sunsite.doc.ic.ac.uk to access here.
:: If you cannot then use the IP address: 155.198.1.40
::
Please read the file README
it was last modified on Sun Jul 9 22:31:21 1995 - 104 days ago
Guest login ok, access restrictions apply.
Please read the file README.DEBIAN
it was last modified on Fri Sep 1 18:07:00 1995 - 50 days ago
Please read the file README.mirrors
it was last modified on Fri Oct 20 13:53:00 1995 - 1 day ago
src:/packages/linux/debian> dir
total 473
drwxr-xr-x 13 root root 1024 Oct 21 01:22 .
drwxr-xr-x 12 root other 512 May 23 19:59 ..
-r--r--r-- 1 root root 123465 Oct 20 07:17 Packages-Master
-r--r--r-- 1 root root36066 Oct 20 07:17 Packages-Master.gz
-r--r--r-- 1 root root 2110 Sep 1 17:07 README.DEBIAN
-r--r--r-- 1 root root 2697 Oct 20 12:53 README.mirrors
drwxr-xr-x 14 root root 512 Oct 21 01:22 binary
drwxr-xr-x 6 root root 512 Sep 23 00:21 contrib
drwxr-xr-x 5 root root 512 Oct 21 00:39 debian-0.93
lrwxrwxrwx 1 root other 11 Sep 29 07:06 debian-0.93R6 ->
debian-0.93
drwxr-xr-x 4 root root 512 Jun 26 00:05 debian-bugs
lrwxrwxrwx 1 root other 11 Sep 29 07:06 debian-current ->
debian-0.93
drwxr-xr-x 2 root root 512 Sep 2 00:16 doc
drwxr-xr-x 2 root root 512 Sep 14 01:02 info
drwxr-xr-x 2 root root 512 Jun 20 02:31 kernel
-r--r--r-- 1 root root 276460 Oct 20 07:50 ls-laR
drwxr-xr-x 5 root root 512 Sep 23 00:21 non-free
drwxr-xr-x 3 root root 512 Sep 23 00:20 private
drwxr-xr-x 5 root root 512 Sep 29 07:06 project
drwxr-xr-x 2 root root 512 Sep 29 07:06 tools
src:/packages/linux/debian> dir binary
total 15
drwxr-xr-x 14 root root 512 Oct 21 01:22 .
drwxr-xr-x 13 root root 1024 Oct 21 01:22 ..
drwxr-xr-x 2 root root 1536 Oct 21 01:22 devel
drwxr-xr-x 2 root root 512 Oct 21 00:43 doc
drwxr-xr-x 2 root root 512 Oct 21 00:31 editors
drwxr-xr-x 2 root root 512 Oct 21 00:31 electronics
drwxr-xr-x 2 root root 512 Oct 21 00:31 games
drwxr-xr-x 2 root root 512 Oct 21 00:31 graphics
drwxr-xr-x 2 root root 512 Oct 21
Re: Mirror sites still having problems
Ian Jackson writes: > > Several mirror sites are *still* in a mess, even after repeated > emails. > > At this point I think we can do one of two things: > > 1. Keep prodding them, phoning them up, &c &c &c &c - any > volunteers ? (If it comes to this I'll deal with > src.doc.ic.ac.uk.) > > 2. Move the whole of ftp.debian.org:/debian to /debian.real, and > replace with an empty /debian containing only `README.vanished'. > Leave for 3 days. Put it back. I hope your joking about this 2nd one, I wouldn't enjoy missing out on your timing of the move and having my mirror delete itself and then refetch the whole damn thing again. Andrew -- Dehydration - 34%, Recollection of previous evening - 2%, embarrassment factor - 91%. Advise repair schedule:- off line for 36 hours, re-boot startup disk, and replace head - wow, what a night! -- Kryten in Red Dwarf `The Last Day' Andrew Howell [EMAIL PROTECTED] Perth, Western Australia [EMAIL PROTECTED]
Bug#1708: passwd' not interruptible when invoked by `adduser'
Hello Ian Jackson!
}Package: adduser? miscutils?
}Version: adduser (1.94-1), miscutils (1.3-2)
No. libc.
}If I run adduser, and then decide to abort after having been presented
}with the password prompt, I can't do it with ^C. passwd apparently
}ignores ^C, and ^D simply produces another passwd prompt. Presumably
}I would have to type in a password twice to escape; instead, I used
}another terminal and killed the adduser process.
Because I have heavily modified the passwd program in the last days I
checked this report...
The reason is not in the adduser nor in the miscutils (or util-linux
where my passwd comes from). It's in the libc itself.
The passwd programm just makes a system call:
-- [passwd.c]
pwdstr = getpass("Enter new password: ");
if (pwdstr[0] == '\0') {
puts("Password not changed.");
exit(1);
}
--
Looking at the source of libc you'll find the code that is responsible
for disabling ^C:
-- [getpass.c] ---
ttyb.c_lflag &= ~(ECHO|ISIG);
ioctl(fileno(tty), TCSETS, &ttyb);
--
The above code (from util-linux) will accept an empty password
(generated with ^D) - and won't change anything. For me this is a
correct behaviour - I can live with that.
I haven't looked at the passwd program that is used by Debian.
So far,
Joey
--
/ Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg /
/ +49-441-777884 * Login&Passwd: nuucp * Index: ~/ls-lR.gz /
/Erfahrung ist eine n|tzliche Sache /
/ Leider macht man sie immer erst kurz nachdem man sie brauchte /
30.10.95: Oldenburger Linux-Stammtisch, ab 20h im DaCapo
Debian Incoming
Hi folks! While uploading a packages just a moment ago, I noticed that files in the Debia Incoming area are of mode 666. So everyone can overwrite them. :-( I noticed it because unfortunately while uploading the connection timed out and normally I am not able to overwrite the empty file, but here I was. I think it would be much better if new files are of mode 644 or 600. What do you think? This behaviour can be easily specified in the ftpaccess file with the following line: # Upload is only allowed to /incoming. All files will be owned by # ftpadmin.ftp with file mod 0644. # upload ~ftp /debian/private/project/Incoming yes ftpadmin ftp 0600 dirs Cheers Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / +49-441-777884 * Login&Passwd: nuucp * Index: ~/ls-lR.gz / /Erfahrung ist eine n|tzliche Sache / / Leider macht man sie immer erst kurz nachdem man sie brauchte / 30.10.95: Oldenburger Linux-Stammtisch, ab 20h im DaCapo
Bug#1682: Re: permissions on directories
Austin Donnelly writes ("permissions on directories"):
> Remember the fiasco with /usr/sbin being world writeable?
>
> Well, I tracked it down: I had a look at the base discs I installed, and
> what do I find:
> /usr/lib/kbd
> /usr/lib/terminfo
> /usr/lib/terminfo/c
> /usr/lib/terminfo/l
> /usr/lib/zoneinfo
> /usr/doc
> /usr/sbin
> are all world writeable.
>
> So it wasn't me playing silly buggers - it was the 3 base discs!
>
> Austin (feeling righteous:)
Don't tell me, tell debian-bugs :-). I've added the number of your
original bug report to the Subject and CC'd this message there.
Bruce: I trust that the latest disks don't have this problem. Do we
know how this happened ?
Ian.
Re: ChangeLog format
Ian Murdock writes ("ChangeLog format"):
> Personally, I like Ian J.'s ChangeLog format--I think it satifies
> both goals of being human-readable and machine-readable.
Would it be helpful if I wrote a spec. saying what the format is, so
that people writing changelogs and programs to manipulate them had a
document telling them what to do ?
Ian.
ChangeLog format
I'd like for all members of the Project to agree on a common format. Frankly, I don't like the one currently implemented in dchanges. I assume there are a few people who agree with me, as not everyone is using dchanges to write their announcements. I'd like to be using a format that is *both* machine-readable and human-readable. The currently-used format is certainly machine- readable, but it isn't human-readable at all. I don't think that these are mutually-exclusive goals. Personally, I like Ian J.'s ChangeLog format--I think it satifies both goals of being human-readable and machine-readable.
rootdisk
A new rootdisk is now available at ftp.debian.org in /debian/private/project/pre-release. This rootdisk changes "Normal Mode" to "Novice Mode" and "Expert Mode" to "Custom Mode", and it makes Custom Mode the default. Also, it supports the new kernel installation scheme by prompting for insertion of the bootdisk after the base system is installed and running the install.sh program from the bootdisk. I'm not moving it into public view yet, however, because there appear to be a few problems with the bootdisk uploaded a few days ago: * The introductory text is mangled. It needs the msdog CRLFs added to it. * install.sh appears to only install part of the image package. It doesn't install the symbolic link /vmlinuz, which is used by dinstall in several places, it doesn't appear to install any of the modules to the appropriate place. I also noticed the following problems with the base system: * /usr/lib/zoneinfo is mode 777. * The audio devices are missing. * dpkg 0.93.77 was installed instead of the most recent version. When you're fixing these bugs, Bruce, please make sure you have a copy of the newest base packages. I moved a new ld.so into the binary/base directory earlier today, and there should be a new sysklogd package fairly soon. (It's in Incoming but not announced yet--I've asked the maintainer to announce it so I can move the package out of Incoming, too.)
watch
The watch package doesn't include a context diff. (I've deleted the announcement, so I don't know who, offhand, is the maintainer.) Why? (I'm leaving it in Incoming for the moment--the only packages that don't need a context diff are packages written specifically by the Project for inclusion in the distribution, like dpkg.)
Bug#1723: fvwm `debian.rules clean' target fails if already clean
Package: fvwm Version: 1.24r-7 The enclosed patch should be applied to debian.rules. Ian. --- debian.rules~ Thu Oct 5 03:33:50 1995 +++ debian.rulesSat Oct 21 16:00:56 1995 @@ -36,7 +36,7 @@ clean: # Undoes the effect of `make -f debian.rules build'. - make clean + -make clean rm -f Makefile fvwm/Makefile libs/Makefile modules/*/Makefile \ xpmroot/Makefile rm -f stamp-build
Mirror sites still having problems
Several mirror sites are *still* in a mess, even after repeated emails. At this point I think we can do one of two things: 1. Keep prodding them, phoning them up, &c &c &c &c - any volunteers ? (If it comes to this I'll deal with src.doc.ic.ac.uk.) 2. Move the whole of ftp.debian.org:/debian to /debian.real, and replace with an empty /debian containing only `README.vanished'. Leave for 3 days. Put it back. Ian.
Bug#1720: adduser: races, and chmod/chown - patch provided
Austin Donnelly writes ("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...
Please see also my bug reports, #1544 and #1500. #1544 contains a
patch that fixes all the problems I've encountered with adduser, and
which will probably overlap with Austin's.
I remember seeing a message on debian-* saying that we have a new
maintainer for adduser - would they please step forward so that we can
dump this lot on them ? :-)
If they don't I suppose I could make an interim release, which might
stop any more people submitting patches for overlapping subsets of
bugs.
Ian.
