Re: watch
Date: Sat, 21 Oct 1995 18:10:22 -0600 From: Bdale Garbee <[EMAIL PROTECTED]> In article <[EMAIL PROTECTED]> you wrote: : 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? Because it's original work, not a Debian-ization of something that exists elsewhere. [...] If there's some other way I should handle this, say so. Nope. Since the package is original work, you did it right. Thanks.
Re: ChangeLog format
There's been some discussion of package announcement file format recently. I have some observations on matters relating to this. Observation #1: There are disconnects between package announcements and the availability of packages in the distribution. 1. Packages are generally announced to debian-changes by the package maintainer immediately after being uploaded. 2. The announced packages generally become available in the general distribution after a delay of up to several days following their announcement. 3. Sometimes, announced packages don't become available in the general distribution until after long delays. 4. Occasionally, announced packages never do become available in the general distribution. Observation #2: It's been opined that the current dchanges(1) package announcement format is very machine-readable. Observation #3: It's been opined that the current dchanges(1) package announcement format is not very human-readable. To address concerns growing out of these observations, current package changes processing might be changed as follows: 1. debain-changes becomes a read-only list, except for a restricted group of subscribers allowed to post there. 2. Instead of being posted to debian-changes, packages announcements would be uploaded with the other package files. Package announcements would be required to be in some particular format which is very machine-readable -- possibly the dchanges(1) format. 3. Mechanized package announcements would be made to debian-changes as packages are moved from Incoming into the general distribution. The mechanized package-announcer would be the usual source of postings to debian-changes. 4. If desired, the very machine-readable package announcement uploaded with the package might be translated into some other format deemed to be more human-readable my the mechanized package-announcer, and posted to debian-changes in that alternative format. [EMAIL PROTECTED] (Bill Mitchell)
Conflicting with a range of revisions...
Well, I've decided to return to Matt Porters' previous split between minicom and lrzsz. One side-effect of this is that I need to make the updated lrzsz package conflict just with minicom-1.71-[1..2] (the ones that included lrzsz). I can't seem to make it do so. I've tried specifying: CONFLICTS: minicom (<1.71-2) | minicom (>1.6) And it doesn't work. It tells me that | is not allowed in conflicts. If I use a comma, it passes the < test (since I've got 1.71-3 installed), but then it sees the > test and croaks which is exactly what it should do if a comma is OR. Is this just not doable? If not, I'll just make it conflict with (<1.71-2), but I thought I'd ask first. Mike. -- "I'm a dinosaur. Somebody's digging my bones."
papersize
The a2gs postinst uses /etc/papersize if it exists or asks the user for the default papersize and writes this to /etc/papersize. The TeX postinst needs this information too, but it can't rely on an installed a2gs. This means code has to be duplicated which could result in incompatibilities and is not a satisfying solution anyway. Could this be included in the base system? I'm willing to write a dialog based perl script modeled after the a2gs script to do papersize configuration. Any other ideas? A related note: Currently I use dialog in perl scripts by using a modified version of dialog.pl that uses perl5's modular features. The result is Dialog.pm, making the use of dialog extremely convenient. How should I make this file available? TeX postinst (not the current but the coming version containing full dialog-guided configuration) will need it. I asked the dialog author if he is interested but got no response. I'll try that again. Nils
Bug#1730: forwarded message from Cron Daemon
Package: xntpd Version: 3.4s-0 The logfile rotation should proceed quietly, without mailing the sysadmin. Add >/dev/null to the call to savelog. Ian. --- start of forwarded message (RFC 934 encapsulation) --- Return-Path: Received: by chiark.chu.cam.ac.uk id m0t6uBY-0002YAC (Debian /\oo/\ Smail3.1.29.1 #29.33); Sun, 22 Oct 95 06:47 GMT Message-Id: <[EMAIL PROTECTED]> X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: From: root (Cron Daemon) To: root Subject: Cron <[EMAIL PROTECTED]> run-parts /etc/cron.weekly Date: Sun, 22 Oct 95 06:47 GMT Rotated `/var/log/httpd/access.log' at Sun Oct 22 06:47:07 GMT 1995. Rotated `/var/log/httpd/error.log' at Sun Oct 22 06:47:10 GMT 1995. Rotated `/var/log/xntpd' at Sun Oct 22 06:47:36 GMT 1995. --- end ---
Bug#1732: Bad arithmetic in new perl packages
Pakckage: perl Version: 5.001-5 Notes: tried a.out only, happens also with 5.001-4, however 5.001-3 is OK Perl seems to be confused making some arithmetic operations (additions). Sometimes the result of $a+=$b, when $a is 0 and $b is 2 happens to be 2.04192 or something similar.
Bug#1731: forwarded message from Cron Daemon
Package: cern-httpd Version: 3.0-4 The logfile rotation should proceed quietly, without mailing the sysadmin. Add >/dev/null to the call to savelog. (I have moved the logfiles on my system, because I wanted to run the httpd as `www' rather than as `root' and it couldn't open the logfiles otherwise. I didn't change the call to savelog, just the list of logfiles to be rotated.) Ian. --- start of forwarded message (RFC 934 encapsulation) --- Return-Path: Received: by chiark.chu.cam.ac.uk id m0t6uBY-0002YAC (Debian /\oo/\ Smail3.1.29.1 #29.33); Sun, 22 Oct 95 06:47 GMT Message-Id: <[EMAIL PROTECTED]> X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: From: root (Cron Daemon) To: root Subject: Cron <[EMAIL PROTECTED]> run-parts /etc/cron.weekly Date: Sun, 22 Oct 95 06:47 GMT Rotated `/var/log/httpd/access.log' at Sun Oct 22 06:47:07 GMT 1995. Rotated `/var/log/httpd/error.log' at Sun Oct 22 06:47:10 GMT 1995. Rotated `/var/log/xntpd' at Sun Oct 22 06:47:36 GMT 1995. --- end ---
Bug#1730: forwarded message from Cron Daemon
Ian Jackson writes: > > Package: xntpd > Version: 3.4s-0 > > The logfile rotation should proceed quietly, without mailing the > sysadmin. Add >/dev/null to the call to savelog. This was fixed in 3.4x-1 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#1732: Bad arithmetic in new perl packages
Fernando wrote to debian-bugs: > Pakckage: perl > Version: 5.001-5 (perl5-porters, this is 5.001m without additional packages). > Notes: tried a.out only, happens also with 5.001-4, however 5.001-3 is OK (5.001-3 == 5.001e). > Perl seems to be confused making some arithmetic operations (additions). > Sometimes the result of $a+=$b, when $a is 0 and $b is 2 happens to be > 2.04192 or something similar. Fernando, I unfortunately have no idea what is causing this. Please provide a short script which shows this behaviour (reliably if possible). Perl5-porters, is this a known bug? Ray -- PATRIOTISM A great British writer once said that if he had to choose between betraying his country and betraying a friend he hoped he would have the decency to betray his country. - The Hipcrime Vocab by Chad C. Mulligan
Re: ChangeLog format
There are two things here: the Changelog format and the announcement format. I think it is probably valuable to separate them. The announcements should contain the Changelog entries since the last announced version, and they also need to contain the MD5 checksums, filenames and file sizes. The Changelog (for a package or the distribution) will contain all the relevant Changelog entries, but no filenames &c. Since individual packages need a Changelog themselves, it makes sense to have the package maintainer write their Changelog in the same format as appears in the release announcements and in the global Changelog. That way they can just cut-and-paste the Changelog entry they have made into the release announcement, append the file information, and send it off. Regarding the delays between announcements on debian-changes and packages' appearance in the distribution directories: I find it very useful to have information about packages which are on their way to Incoming - this means I can grab them out of there (when they're completely uploaded) without having to wait for anyone to move packages or make announcements. This can also be important for programs with security problems or other urgent bugfixes. We shouldn't just move packages automatically out of incoming, because this would make us far too vulnerable to random people uploading bogus stuff, so this delay can't be eliminated. The conclusion I come to is that there should be at least two lists - one which announces the packages when they're released by the maintainer (and which perhaps has an automatically-generated report from the FTP site maintainer when packages are moved), and one which announces them as they are moved into view. I attach below copies of the only programs (apart from Emacs) I use to generate my Changelog entries. They're pretty much hand-edited: I copy the last version's entry, delete the text, and use the `822-date' script to produce a sensible dateline. I use the equivalent of `md5sum *' and `ls -al *' to produce the MD5 checksum, filename &c information at the bottom of my announcements. Note that none of what I'm saying above means that we need a horrible un-human-readable changelog or announcement format at any stage. My format is perfectly machine-readable. If people want me to write scripts to parse my changelog entries and release announcements I'd be only too happy to do so, or to document my format so that they can doo it. Ian.
Bug#1733: ncftp problems
Firstly, if I a transfer (say from ftp.debian.org) is aborted halfway through, attempting to get the same file produces the incorrect message `Already have ', and I have to use `-f'. Secondly, ncftp should have been compiled with readline support :-). Ian. debian:/debian/private/project/Incoming> get sysklogd-1.2-13.deb sysklogd-1.2-13.deb: 60% [1]+ Stopped ncftp debian You have mail in /usr/spool/mail/ian -chiark:~> kill %1 [1]+ Stopped ncftp debian -chiark:~> ncftp debian NcFTP 2.1.0 (July 15, 1995), by Mike Gleason, NCEMRSoft. Current local directory is /u/ian/download. Trying to connect to ftp.debian.org... ** WELCOME TO C E N T R A L M I C H I G A N U N I V E R S I T Y DEPARTMENT OF COMPUTER SCIENCE ** Hello, user at chiark.chu.cam.ac.uk. You are currently user 8 out of a possible 200 in your class. If you experience problems with this archive or if you have comments or questions about this archive, please contact [EMAIL PROTECTED] Anonymous users: Please use a real e-mail address as your password, not "root", "Netscape", "WWWuser", etc., and please keep the number of connections to one. If this becomes a problem, we will deny access to your machine, or even to your entire domain. The official Debian GNU/Linux archive is located on this machine in the directory /debian. NOTE: This site allows the .tar.gz convention, but please note that 99% of the files on this site are already compressed. Therefore, .gz should not be used, as it creates unnecessary load on the server. Guest login ok, access restrictions apply. The current version of Debian GNU/Linux is 0.93 Release 6. For more information about Debian GNU/Linux, please visit the World Wide Web page http://www.debian.org/. Please read the file README.DEBIAN it was last modified on Fri Sep 1 14:07:45 1995 - 51 days ago Please read the file README.mirrors it was last modified on Fri Oct 20 09:53:02 1995 - 2 days ago debian:/debian> private/project/Incoming Permission denied. debian:/debian/private/project/Incoming> dir total 9928 -rw-rw-rw- 1 0 debian36046 Oct 21 23:17 bc-1.03-8.deb -rw-rw-rw- 1 0 debian20782 Oct 21 23:16 bc-1.03-8.diff.gz -rw-rw-rw- 1 0 debian 121749 Oct 21 23:16 bc-1.03-8.tar.gz -rw-rw-rw- 1 0 debian24010 Oct 21 23:18 dc-1.03-8.deb -rw-rw-rw- 1 0 debian 172372 Oct 21 23:18 diff-2.7-5.deb -rw-rw-rw- 1 0 debian 8982 Oct 21 23:16 diff-2.7-5.diff.gz -rw-rw-rw- 1 0 debian 318922 Oct 21 23:17 diff-2.7-5.tar.gz -rw-rw-rw- 1 0 debian98572 Oct 21 23:18 ed-0.2-8.deb -rw-rw-rw- 1 0 debian 7572 Oct 21 23:17 ed-0.2-8.diff.gz -rw-rw-rw- 1 0 debian 192588 Oct 21 23:17 ed-0.2-8.tar.gz -rw-rw-rw- 1 0 debian95327 Oct 21 23:18 indent-1.9.1-12.deb -rw-rw-rw- 1 0 debian 5442 Oct 21 23:17 indent-1.9.1-12.diff.gz -rw-rw-rw- 1 0 debian 164424 Oct 21 23:17 indent-1.9.1-12.tar.gz -rw-rw-r-- 1 1 debian43066 Oct 21 15:40 infocom-4.01pl2-1.deb -rw-rw-r-- 1 1 debian 3139 Oct 21 15:40 infocom-4.01pl2-1.diff.gz -rw-rw-r-- 1 1 debian85637 Oct 21 15:40 infocom-4.01pl2-1.tar.gz -rw-rw-rw- 1 0 debian30720 Oct 22 13:38 netbase-1.19-1-diffs.tar -rw-rw-rw- 1 0 debian 337920 Oct 22 13:42 netbase-1.19-1-src.tar -rw-rw-rw- 1 0 debian 172269 Oct 22 13:40 netbase-1.19-1.deb -rw-rw-rw- 1 0 debian 402 Oct 22 13:39 netbase-1.19-1.md5 -rw-rw-rw- 1 0 debian 194560 Oct 22 13:45 netstd-1.19-1-diffs.tar -rw-rw-rw- 1 0 debian 1771520 Oct 22 14:09 netstd-1.19-1-src.tar -rw-rw-rw- 1 0 debian 647650 Oct 22 14:14 netstd-1.19-1.deb -rw-rw-rw- 1 0 debian 396 Oct 22 14:10 netstd-1.19-1.md5 -rw-rw-rw- 1 0 debian84706 Oct 21 23:18 sharutils-4.1-7.deb -rw-rw-rw- 1 0 debian 9739 Oct 21 23:17 sharutils-4.1-7.diff.gz -rw-rw-rw- 1 0 debian 175230 Oct 21 23:17 sharutils-4.1-7.tar.gz -rw-rw-r-- 1 1 debian23868 Oct 21 15:40 sysklogd-1.2-13.deb -rw-rw-r-- 1 1 debian15516 Oct 21 15:40 sysklogd-1.2-13.diff.gz -rw-rw-r-- 1 1 debian36042 Oct 21 15:40 sysklogd-1.2-13.tar.gz -rw-rw-r-- 1 1 debian 2946 Oct 21 15:40 watch-1.0-1.deb -rw-rw-r-- 1 1 debian 6424 Oct 21 15:40 watch-1.0-1.tar.gz debian:/debian/private/project/Incoming> get sysklogd-1.2-13.deb Already have sysklogd-1.2-13.deb. debian:/debian/private/project/Incoming> get -f sysklogd-1.2-13.deb sysklogd-1.2-13.deb: sysklogd-1.2-13.deb: 23868 bytes received in 8.78 seconds, 2.65 kB/s. debian:/debian/private/project/Incoming>
Re: papersize
On Sun, 22 Oct 1995, Nils Rennebarth wrote: >[...] > Could this be included in the base system? > > I'm willing to write a dialog based perl script modeled after the a2gs > script to do papersize configuration. > > Any other ideas? Someone -- Ian J. I think -- once fielded a package which set up a default /etc/papersize with a guess based on the system's timezone. Seemed like a neat idea to me. I wonder if all of the Americas use U.S. papersizes. I think Asian countries generally use U.S. sizes as well. Does Africa use European papersizes? How about the Mideast? H ex Soviet block, Asia, Mideast, and Australia share timezones. Maybe it's not so neat a solution after all.
Bug#1734: netstd 1.19-1 won't install
Package: netstd Version: 1.19-1 While upgrading from netstd 1.71-1 to 1.19-1, I saw: Installing new version of config file /etc/init.d/netstd_misc ... There is already an entry for #systat in /etc/inetd.conf, but I don't recognise it. Here is what it looks like: #systatstream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx Do you want to ignore this potential problem and continue, or would you rather not do so now ? Continue? (n/y) y dpkg: error processing netstd (--install): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: netstd [EMAIL PROTECTED]:~/download> dpkg --configure netstd Setting up netstd ... There is already an entry for telnet in /etc/inetd.conf, but I don't recognise it. Here is what it looks like: telnet stream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.telnetd Do you want to ignore this potential problem and continue, or would you rather not do so now ? Continue? (n/y) y dpkg: error processing netstd (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: netstd [EMAIL PROTECTED]:~/download> At this point I took a copy of my inetd.conf (enclosed below), edited out the entry for systat, and tried again: [EMAIL PROTECTED]:~/download> dpkg --configure netstd Setting up netstd ... There is already an entry for telnet in /etc/inetd.conf, but I don't recognise it. Here is what it looks like: telnet stream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.telnetd Do you want to ignore this potential problem and continue, or would you rather not do so now ? Continue? (n/y) y dpkg: error processing netstd (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: netstd [EMAIL PROTECTED]:~/download> Grrr. I edited that out too, tried again, and it replaced it with an identical-looking entry. Then I got a prompt about shell stream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.rshd I give up. Unfortunately I can't revert to 1.18 because of the security problem with fingerd. Ian. # /etc/inetd.conf: see inetd(8) for further informations. # $Id: inetd.conf,v 1.2 1995/07/17 22:45:21 tobias Exp $ # # Internet server configuration database # # # # #:INTERNAL: Internal services echostream tcp nowait rootinternal echodgram udp waitrootinternal discard stream tcp nowait rootinternal discard dgram udp waitrootinternal daytime stream tcp nowait rootinternal daytime dgram udp waitrootinternal chargen stream tcp nowait rootinternal chargen dgram udp waitrootinternal timestream tcp nowait rootinternal timedgram udp waitrootinternal #:STANDARD: These are standard services. telnet stream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.telnetd ## ftp stream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.ftpd #fspdgram udp waitroot/usr/sbin/tcpd /usr/sbin/in.fspd ftpstream tcp nowait root/usr/sbin/tcpd /usr/sbin/wu-ftpd #:BSD: Shell, login, exec and talk are BSD protocols. shell stream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.rshd login stream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.rlogind #exec stream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.rexecd talkdgram udp waitroot/usr/sbin/tcpd /usr/sbin/in.talkd ntalk dgram udp waitroot/usr/sbin/tcpd /usr/sbin/in.ntalkd #:MAIL: Mail, news and uucp services. smtpstream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.smtpd 118 stream tcp nowait news/usr/sbin/tcpd /usr/local/sbin/nnrpwrap #nntp stream tcp nowait news/usr/sbin/tcpd /usr/sbin/in.nntpd #uucp stream tcp nowait uucp/usr/sbin/tcpd /usr/lib/uucp/uucico comsat dgram udp waitroot/usr/sbin/tcpd /usr/sbin/in.comsat pop-2 stream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.pop2d pop-3 stream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.pop3d #:INFO: `cfinger' is for the GNU finger server available for Debian. # (NOTE: The current implementation of the `finger' daemon allows it to # be run as `root'.) #cfinger stream tcp nowait root/usr/sbin/tcpd /usr/sbin/in.cfingerd finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in.fingerd ident stream tcp nowait nobody /usr/sbin/identd /usr/sbin/identd -l #netstatstream tcp nowait nobody /usr/sbin/tcpd /bin/netstat #systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx httpstream tcp nowait www /usr/sbin/httpd /usr/sbin/httpd #:BOOT: Tftp service is provided primarily for booting. Most sites # run this only o
Re: Bug#1724: unexpected keypress translations
Bill Mitchell writes ("Bug#1724: unexpected keypress translations"):
> 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.
You should have expected that. Different terminals have different
escape sequences, and an xterm is not the same as a Linux console.
I'm marking this bug as done.
If you have a program that doesn't correctly use the terminal
information databases (termcap or terminfo) to interpret keystroke
escapes then that program is buggy.
> 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).
No, it's not another issue.
Ian.
Re: ChangeLog format
On Sun, 22 Oct 1995, Ian Jackson wrote:
> There are two things here: the Changelog format and the announcement
> format. I think it is probably valuable to separate them.
Yes. I've been following a practice of cutting my most recent
ChangeLog entry out and using it verbatim in the package announcement.
Occasionally, I'll put some additional info in the ChangeLog and
just cut the final portion of the final entry for the announcement.
When I went to the dchanges(1) format, I went to that format in
the ChangeLog as well (the Priority and Changes fields are there).
> The announcements should contain the Changelog entries since the last
> announced version, and they also need to contain the MD5 checksums,
> filenames and file sizes.
This gets a bit specific to the working style I've developed, but
it might be useful to discuss it. Others might find it useful,
or I might pick up something useful from reactions.
packages/work/
doit (a badly-named package building script)
sendlist (for kermit: "take sendlist")
-/ (several of these)
--.{*.gz, *.deb} (latest ones)
old/ (old .gz and .deb files)
changes (announcement stuff cut from most recent ChangeLog)
-.orig/ (upstream sources)
-/ (debian working directory)
The doit script builds one or more packages for distribution.
It checks that the changes file is more recent than the package
ChangeLog file, builds the package, symlinks .gz and .deb
filenames to files in the - directory,
runs "dchanges -n -c -/changes "
to produce --.changes, and appends
names of the package files and the changes file to sendlist.
The dchanges program puts md5sums, sizes, etc. into the
--.changes file for me.
All this is a bit structured for maintainers with just a few
packages, but I've got about 20.
> The Changelog (for a package or the distribution) will contain all the
> relevant Changelog entries, but no filenames &c.
I've got some misgivings about mandating stuff like this. It seems
to be getting a bit deep into micro-managing how individual maintainers
go about doing their source package housekeeping.
I recognize the value in having everybody do this the same way,
but we (the whole team of maintainers) have not been very successful
in managing to do things which have a visible impact on the
distribution in a completely consistent manner. Compliance (or not)
with this would be invisible, unless someone took on the job of
ChangeLog Policeman and nagged violators.
Actually, I'd be one of the violaters nagged in any case.
I'm not keeping separate ChangeLog files in my debian source
packages (I tried it for a while, and dropped it). I'm
appending ChangeLog info to the debian.README file. My
packages generally only add files named debian.something
to the upstream sources, and seek to minimize changes to
upstream source files. Debianizing a new upstream release
is usually pretty easy -- copying debian.* from the current
package and editing debian.rules and debian.README generally
does most of what needs doing. Aside from the added debian.*
files, there's usually little or no difference between my
source packages and the upstream sources.
Is the name "ChangeLog" and the format you favor an emacs thing?
I'm not an emacs person, and wouldn't know about emacs-isms.
> Regarding the delays between announcements on debian-changes and
> packages' appearance in the distribution directories:
>
> I find it very useful to have information about packages which are on
> their way to Incoming - this means I can grab them out of there (when
> they're completely uploaded) without having to wait for anyone to
> move packages or make announcements.
>
> This can also be important for programs with security problems or
> other urgent bugfixes.
But I don't think it's useful to have packages announced to the
world at large several days before they show up, and less useful
to have packages announced which never do show up. Perhaps we
could use (yet)another mailing list for this, with mechanized
announcements from debian.org of new packages seen in Incoming.
> We shouldn't just move packages automatically out of incoming, because
> this would make us far too vulnerable to random people uploading bogus
> stuff, so this delay can't be eliminated.
Right, but announcing them before they're available is questionable,
and announcing packages which never show up moreso.
> The conclusion I come to is that there should be at least two lists -
> one which announces the packages when they're released by the
> maintainer (and which perhaps has an automatically-generated report
> from the FTP site maintainer when packages are moved), and one which
> announces them as they are moved into view.
That's pretty much the conclusion I came to as well.
>[...]
> Note that none of what I'm saying above means that we need a horrible
> un-human-readable changelog or announcement format at any stage. My
> format is perfectly machine-readable
Bug#1733: ncftp problems
> Firstly, if I a transfer (say from ftp.debian.org) is aborted halfway > through, attempting to get the same file produces the incorrect > message `Already have ', and I have to use `-f'. Ever thought of the -C instead of -f? ncftp 2.2.0 is out now in any case - I wonder if the author has implimented any changes to this? ...Karl -- | PO Box 828 Office: (09)316-3036 Fax: (09)381-3909 |OWER INTERNET SERVICES Canning Bridge After Hours: 015-779-828 WA, 6153 Sales Support: [EMAIL PROTECTED] Internet Service Providers and Networking Solutions
Bug#1732: Bad arithmetic in new perl packages
On Sun, 22 Oct 1995, J.H.M.Dassen wrote: > Fernando wrote to debian-bugs: (problem with 5.001m, but not 5.001e) > > Perl seems to be confused making some arithmetic operations (additions). > > Sometimes the result of $a+=$b, when $a is 0 and $b is 2 happens to be > > 2.04192 or something similar. Without seeing a short example script, it's dangerous to guess, but I'll do so anyway. There is a very subtle bug that can arise in some rare situations where perl has to convert back and forth between string and floating point representations, but that's almost certainly not the problem here. I also can't think of anything in 5.001m (as opposed to 5.001e) that might have affected this. I'd guess one of two things is going on: 1. This is the usual sort of problem that arises when folks forget that floating point arithmetic isn't exact. Perl5 is pretty forgiving, and tries hard to print what you want, but doesn't always succeed. 2. The tests are running on a buggy pentium :-). > Fernando, I unfortunately have no idea what is causing this. Please > provide a short script which shows this behaviour (reliably if possible). Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: ChangeLog format
Bill Mitchell writes: > Horrible, etc. seems a bit harsh. I'm not rabid about the dchanges > format (which, after all, wasn't my idea in the first place), but I > don't think it's all that bad. I think having the dchanges tool > available to syntax check it before uploading is a big plus if > it's supposed to be machine-parsed after uploading. If the group > wants to go to some other format, and someone is willing to field, > document, and maintain a tool to support building and syntax-checking > package announcements using that format, I'll retire dchanges(1) and > switch with little or no complaint. I like dchanges for the simple fact that it does the tiresome md5sum and size of file work for me, and it's standardised many of the package annoucements. If we switch to something else I'd want a similiar tool to dchanges. I don't think dchanges output is that unreadable. 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#1735: apropos(1) segfaults
PACKAGE: man VERSION: 2.3.10-2 Script started on Sun Oct 22 18:55:28 1995 root:/root# apropos inode utime (2)- change access and/or modification times of an inode Segmentation fault (core dumped) root:/root# apropos cat Segmentation fault (core dumped) root:/root# apropos crap Segmentation fault (core dumped) root:/root# Script done on Sun Oct 22 18:55:58 1995 [EMAIL PROTECTED] (Bill Mitchell)
Bug#1735: apropos(1) segfaults
Bill Mitchell writes: > PACKAGE: man > VERSION: 2.3.10-2 > > Script started on Sun Oct 22 18:55:28 1995 > root:/root# apropos inode > utime (2)- change access and/or modification times of an inode > Segmentation fault (core dumped) > root:/root# apropos cat > Segmentation fault (core dumped) > root:/root# apropos crap > Segmentation fault (core dumped) > root:/root# > Script done on Sun Oct 22 18:55:58 1995 > > [EMAIL PROTECTED] (Bill Mitchell) I've had this problem before as well, but I discovered that the man database was screwed up and forcing it to rebuild it with mandb fixed it. Still it shouldn't really core dump even if the database is corrupt. 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]
Re: ChangeLog format
I realised I didn't attach the scripts I use to my previous message.
---8<--- /usr/local/bin/822-date
#!/usr/bin/perl --
# I hereby place this in the public domain - Ian Jackson, 1995.
@ARGV && die "usage: 822-date\n";
$x=time; sub z { $_[1]+$_[2]*60; }; @l=localtime($x); $od=1440;
$d=&z(@l)-&z(gmtime($x)); $d+=$od; $d%=$od; $s=$d>$od/2?($d=$od-$d,'-'):'+';
printf("%s, %d %s %d %02d:%02d:%02d %s%02d%02d\n",
(Sun,Mon,Tue,Wed,Thu,Fri,Sat)[$l[6]], $l[3],
(Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec)[$l[4]], $l[5]+1900,
$l[2],$l[1],$l[0], $s,$d/60,$d%60) || die "822-date: output error: $!\n";
---8<---
---8<--- ~/things/debian/buildit.sh
#!/bin/sh
set -e -x
really ./debian.rules clean
./debian.rules diff source
./debian.rules build
really ./debian.rules binary
---8<---
---8<--- ~/things/debian/Upload.sh
#!/bin/sh -
set -e
if [ 0 = $# ]
then
set -- *-*.*.{deb,diff.gz,tar.gz}
fi
for f in "$@"
do
if test -f "$f"
then
md5sum "$f"
fi
done
for f in "$@"
do
if test -f "$f"
then
ls -ald -- "$f"
cp $f $HOME/out/.
mv $f upl/.
fi
done
---8<---
Re: ChangeLog format
Andrew Howell writes ("Re: ChangeLog format"):
> I like dchanges for the simple fact that it does the tiresome md5sum
> and size of file work for me, and it's standardised many of the package
> annoucements. If we switch to something else I'd want a similiar tool
> to dchanges. I don't think dchanges output is that unreadable.
To get the md5sum and size of the files I use `md5sum *.{deb,gz}' and
`ls -l *.{deb,gz}'.
What precisely does dchanges take as input ?
I'd be happy to produce a tool to replace dchanges which produces
announcements in my format instead.
Ian.
Bug#1724: unexpected keypress translations (fwd)
Bill Mitchell writes ("Re: Bug#1724: unexpected keypress translations (fwd)"):
> The program in question is ae. I thought I'd pass this on
> to you. ae uses raw keypress defs in the config file, leading
> to this problem. I'm guessing that may have been a size or
> complexity tradeoff. The keypresses in question are PC
> function keys, which generate different escape sequences
> at the non-X11 linux console and in an xterm.
Well, that won't work. How does ae drive the screen ? Whatever
library it's using for that will provide a facility for interpreting
(or at least determining) function key sequences.
I've reopened this bug and assigned it to the `ae' package.
Ian.
> -- Forwarded message --
> Date: Sun, 22 Oct 95 18:40 GMT
> From: Ian Jackson <[EMAIL PROTECTED]>
> To: Bill Mitchell <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> Debian developers list <[EMAIL PROTECTED]>
> Subject: Re: Bug#1724: unexpected keypress translations
>
> Bill Mitchell writes ("Bug#1724: unexpected keypress translations"):
> > 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.
>
> You should have expected that. Different terminals have different
> escape sequences, and an xterm is not the same as a Linux console.
>
> I'm marking this bug as done.
>
> If you have a program that doesn't correctly use the terminal
> information databases (termcap or terminfo) to interpret keystroke
> escapes then that program is buggy.
>
> > 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).
>
> No, it's not another issue.
>
> Ian.
>
Re: ChangeLog format
Bill Mitchell writes ("Re: ChangeLog format"):
> All this is a bit structured for maintainers with just a few
> packages, but I've got about 20.
I have a total of about 20 lines of script to do all of my changelog
generation, and I have about 10 packages.
I think there are some people who are doing an awful lot of automatic
copying of information from one place to another, with reformatting
en-route ...
> > The Changelog (for a package or the distribution) will contain all the
> > relevant Changelog entries, but no filenames &c.
>
> I've got some misgivings about mandating stuff like this. It seems
> to be getting a bit deep into micro-managing how individual maintainers
> go about doing their source package housekeeping.
>
> [ stuff about per-package Changelog files ]
I didn't intend to make a comment about how package maintainers should
organise the changelog in the package (I think they should keep one,
but putting that in the guidelines may be too strong).
I was just saying that a changelog file, as a log of changes, doesn't
need to contain information about the md5 checksums &c of each
released version.
> Is the name "ChangeLog" and the format you favor an emacs thing?
> I'm not an emacs person, and wouldn't know about emacs-isms.
I favour the name Changelog (note lowercase L) because I don't like
capitals in the middle of words.
My preferences are nothing to do with Emacs (indeed, Emacs has a mode
for generating changelogs that look different to mine and are IMO
inferior for our purposes, and it likes to use the capital L). I
happen to use Emacs to create it, but I to do it only use features of
Emacs common to almost all text editors.
If someone wants a fancy Emacs mode to edit Changlogs in my format I
can do that too, though I find that cut-and-paste and a bit of use of
the fill-prefix to get the change entries to word-wrap to the correct
left-hand margin is quite sufficient.
> Horrible, etc. seems a bit harsh. I'm not rabid about the dchanges
> format (which, after all, wasn't my idea in the first place), but I
> don't think it's all that bad. I think having the dchanges tool
> available to syntax check it before uploading is a big plus if
> it's supposed to be machine-parsed after uploading. If the group
> wants to go to some other format, and someone is willing to field,
> document, and maintain a tool to support building and syntax-checking
> package announcements using that format, I'll retire dchanges(1) and
> switch with little or no complaint.
I'll build whatever tools people want, if they specify them.
I think the problem I have here is that my way of working doesn't
involve having a tool that generates release announcements. I make
them by cutting and pasting the easily hand-edited Changelog entry
into my mailer, together with the output from my `Upload.sh' script
(which basically does md5sum * and ls -l *, as I said before). This
all seems far too trivial for me to try to turn these tiny scripts
into released software. Surely people who are building software for
release and hacking debian.rules files and so forth can write a 5 or
10-line utility shellscript to fit their way of working ?
Ian.
Bug#1735: apropos(1) segfaults
Andrew Howell writes ("Bug#1735: apropos(1) segfaults"):
> Bill Mitchell writes:
> > root:/root# apropos crap
> > Segmentation fault (core dumped)
> > root:/root#
> > Script done on Sun Oct 22 18:55:58 1995
>
> I've had this problem before as well, but I discovered that the man database
> was screwed up and forcing it to rebuild it with mandb fixed it. Still it
> shouldn't really core dump even if the database is corrupt.
Then there are at least two or three bugs:
1a. The database got corrupted.
1b. The database didn't get fixed because the corruption wasn't
detected, or because no appropriate action was taken. If
corruption is made sufficiently rare then having it automatically
un-corrupt it on demand is less necessary. This is obviously
better than having it get corrupted and then be fixed.
2. `apropos' dumps core when fed a corrupted database.
Ian.
