Bug#1750: tar doesn't handle default remote arguments
Package: tar Version: 1.11.8 When attemping to do remote tar operations using the archive name systax specified in the info file, which is "[EMAIL PROTECTED]:file", if user is not specified, tar core dumps, when it should use the current username as the default. This is probably part of the same problem that resulted in bug report #1110, but the problem is sufficiently different from what was reported before that I decided to elaborate. Feel free to attach this to bug #1110 if that seems appropriate. You can duplicate this by doing tar tvf winfree:/dev/nrst0 when logged into hipshack as 'bdale', which will generation a segmentation violation core dump, while using tar tvf [EMAIL PROTECTED]:/dev/nrst0 works fine. Blech.
Bug#1732: Bad arithmetic in new perl packages (fwd)
Forwarded message:
>From [EMAIL PROTECTED] Mon Oct 23 17:47:44 1995
Date: Mon, 23 Oct 1995 12:47:22 -0400 (EDT)
From: Fernando <[EMAIL PROTECTED]>
To: "J.H.M.Dassen" <[EMAIL PROTECTED]>
Subject: Re: Bug#1732: Bad arithmetic in new perl packages
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
While trying to isolate the bug in perl-5.001-5 I managed to reproduce it
also with perl-5.001-3, although the output is not exactly the same.
I have tried the script below in two machines (a 386SX and a 486DX) with
the same result. It seems to be some conversion problem. It happens more
often in perl-5.001m because I noticed when I upgraded and my scripts
started to fail.
This is the test script:
#!/usr/bin/perl
@array=(
"item1 4 units",
"item2 1.5 units",
"item3 8 units + see item2"
);
foreach (@array) {
if( ($item_name,$amount,$unit,$delimiter,$moreinfo)=
/^(\w+)\s*([\d\.]+)\s*(\w+)\s*(\+|$)\s*(.*)/) {
$total+=$amount;
}
}
$Total=$total;
print "total=$total\n";
print "Total=$Total\n";
-
Output from perl-5.001-5:
total=13.5
Total=13.53576
Output from perl-5.001-3:
total=13.5
Total=13.55364
Thanks,
Fernando.
--
J.H.M. Dassen | RUMOUR Believe all you hear. Your world may
[EMAIL PROTECTED] | not be a better one than the one the blocks
[EMAIL PROTECTED] | live in but it'll be a sight more vivid.
| - The Hipcrime Vocab by Chad C. Mulligan
Bug#1732: Bad arithmetic in new perl packages (fwd)
J.H.M.Dassen writes:
>
> #!/usr/bin/perl
>
> @array=(
> "item1 4 units",
> "item2 1.5 units",
> "item3 8 units + see item2"
> );
>
> foreach (@array) {
> if( ($item_name,$amount,$unit,$delimiter,$moreinfo)=
> /^(\w+)\s*([\d\.]+)\s*(\w+)\s*(\+|$)\s*(.*)/) {
> $total+=$amount;
> }
> }
>
> $Total=$total;
> print "total=$total\n";
> print "Total=$Total\n";
> -
>
> Output from perl-5.001-5:
> total=13.5
> Total=13.53576
>
> Output from perl-5.001-3:
> total=13.5
> Total=13.55364
>
No problem here, OS/2, 486/66x2 (1.5 years old).
It would help if you report the version of perl (perl -v) (there is no
such guy as 5.001-5), OS, compiler. Run myconfig.
Ilya
Bug#1732: Bad arithmetic in new perl packages
> : > 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? > > No. Another possibility is that the compiler is using single-precision > instead of double-precision floats. I think you get about 7 digits of > accuracy in single precision. Larry, I've forwarded Fernando's script to perl5-porters. The perl5 package was compiled using Debian's gcc package (gcc 2.6.3) in a.out binary format using '-O2 -fomit-frame-pointer' optimization; the libc is Linux libc-4.6.27. The output differs in the 10th decimal. The weird thing is that it appears when copying the value. I cannot reproduce the bug on the following configurations: FreeBSD 2.1.0, perl 5.001m SunOS 4.1.4,perl 5.000 HP-UX 9,perl 5.000 IRIX 5.3, perl 5.000 perl5-porters, please try to reproduce this - on an non-linux system (with 5.001m) - on a linux system (with a non-debian 5.001m) - on a debian linux system under ELF (my home-machine is not net.connected). Regards, Ray -- LEADERSHIP A form of self-preservation exhibited by people with auto- destructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. - The Hipcrime Vocab by Chad C. Mulligan
Bug#1751: corrupt man page for dc
Package: dc Version: 1.03-8 When running the command mandb -c, I got the message: Processing manual pages under /usr/man... mandb: warning: /usr/man/man1/dc.1: whatis parse for dc(1) failed I recall some comments on mandb recently, so I apologize for this possible redundancy; the bug logs aren't available for checking just now. I am using: base0.93.6 10 dpkg 1.0.5 0 source 1.2.13 4 Susan Kleinmann [EMAIL PROTECTED]
Re: changes file format
The following is taken from an email message I received from [EMAIL PROTECTED] I hope he doesn't object to my posting his email and my responses to debian-devel. I think points made here could usefully contribute to the changes file format discussion. > In article <[EMAIL PROTECTED]> Bill Mitchell <[EMAIL PROTECTED]> writes: > > > Just out of curiosity, does the following represent a horribly > > formatted and human-unreadable package announcement? Except for > > the lack of a Priority field, it passes the dchanges(1) syntax check. > > I omitted it because i didn't have a good idea what to write into it. > (And I hoped that nobody will notice it ...) Perhaps I should have made it clearer that I was holding your package announcement up as an example of a readable announcement produced with dchanges(1). Personally, I thought it was very clear and readable. dchanges(1) requires a Priority field because there was one in the package announcement format example from Bruce Perens, on which dchanges(1) was based. I've been filling it in with whatever seemed to fit (e.g., Emergency, High, Routine, Low, Important, Immediate). My guess is that it's intended to be evaluated by a human. > And the Changelog is hand-edited from a GNU Changelog-formatted file. > An automatic conversion would be nice. No doubt this could be easily done, if I knew exactly what the GNU Changelog format looked like. If it's what I think it is, I'd probably indent all lines with text by one single blank, and convert totally blank lines to " ." lines. I wouldn't plan to do this, however, until the recently-reopened discussion regarding what package announcements should look like and what tools should be used to produce them is done with, and the future (or lack thereof) of the dchanges package is decided. > another BTW: How do I specify that a package should go into the > non-commercial section ? (The answer to this could belong into the > manpage.) What I've seen done, and done myself in that situation, is to include a plaintext intro in the package announcemant to the effect that "This package should go in non-free (or wherever) because ". I haven't had occasion to do this since I fielded the dchanges package. If I did it using dchanges, I'd probably put "SECTION: non-free", or whatever, in the package Control file. I'd probably include that same information in plaintext in the debian-changes posting outside of the portion of the text imported from the changes file produced by dchanges(1) (or whatever tool replaces it).
Bug#1751: corrupt man page for dc
"Susan G. Kleinmann" <[EMAIL PROTECTED]> said: > When running the command mandb -c, I got the message: > Processing manual pages under /usr/man... > mandb: warning: /usr/man/man1/dc.1: whatis parse for dc(1) failed I'm going to try to reassign this bug report from dc to man. When I tried to reproduce it on my system, I saw the following: Script started on Tue Oct 24 07:19:51 1995 # mandb -c Processing manual pages under /usr/man... mandb: warning: /usr/man/man8/in.smtpd.8: whatis parse for in.smtpd(8) failed mandb: warning: /usr/man/man8/mailq.8: whatis parse for mailq(8) failed mandb: warning: /usr/man/man8/sendmail.8: whatis parse for sendmail(8) failed mandb: warning: /usr/man/man8/runq.8: whatis parse for runq(8) failed mandb: warning: /usr/man/man8/rmail.8: whatis parse for rmail(8) failed mandb: warning: /usr/man/man8/rsmtp.8: whatis parse for rsmtp(8) failed mandb: warning: /usr/man/man1/uupath.1: whatis parse for uupath(1) failed mandb: warning: /usr/man/man1/dc.1: whatis parse for dc(1) failed Checking for stray cats under /usr/man... Checking for stray cats under /var/catman... 9 man subdirectories contained newer manual pages. 1196 manual pages and 0 stray cats were added. # Script done on Tue Oct 24 07:20:07 1995 This was with man-2.3.10-2.
Bug#1751: corrupt man page for dc
I should have noted that: -- I was also using man-2.3.10-2, and -- when I ran mandb, I got no other error messages than the one associated with dc. Other than the message about dc, running mandb -c had (for me) the desired beneficial effect of eliminating an error message I kept getting from 'apropos' after I'd manually placed some pages in /usr/local/man/manl. Susan === > "Susan G. Kleinmann" <[EMAIL PROTECTED]> said: > > > When running the command mandb -c, I got the message: > > Processing manual pages under /usr/man... > > mandb: warning: /usr/man/man1/dc.1: whatis parse for dc(1) failed > > I'm going to try to reassign this bug report from dc to man. > When I tried to reproduce it on my system, I saw the following: > Bill Mitchell ,[EMAIL PROTECTED]> said: > Script started on Tue Oct 24 07:19:51 1995 > # mandb -c > Processing manual pages under /usr/man... > mandb: warning: /usr/man/man8/in.smtpd.8: whatis parse for in.smtpd(8) failed > mandb: warning: /usr/man/man8/mailq.8: whatis parse for mailq(8) failed > mandb: warning: /usr/man/man8/sendmail.8: whatis parse for sendmail(8) failed > mandb: warning: /usr/man/man8/runq.8: whatis parse for runq(8) failed > mandb: warning: /usr/man/man8/rmail.8: whatis parse for rmail(8) failed > mandb: warning: /usr/man/man8/rsmtp.8: whatis parse for rsmtp(8) failed > mandb: warning: /usr/man/man1/uupath.1: whatis parse for uupath(1) failed > mandb: warning: /usr/man/man1/dc.1: whatis parse for dc(1) failed > Checking for stray cats under /usr/man... > Checking for stray cats under /var/catman... > 9 man subdirectories contained newer manual pages. > 1196 manual pages and 0 stray cats were added. > # > Script done on Tue Oct 24 07:20:07 1995 > > This was with man-2.3.10-2. > > ===
Bug#1752: inewsinn recommends trn
Package: inewsinn Version: 1.4sec-7 I find it *really* annoying that inewsinn recommends trn, since I want tin, which requires inewsinn or inn, but don't want trn. This makes me have to go through conflict resolution every time. Isn't it sufficient that trn and tin require inn or inewsinn? Bdale
Bug#1753: trn recommends, instead of depends
Package: trn Version: 3.6-2 It's not clear to me why trn uses 'recommends' for a mail transport and a news article injector, while tin uses 'depends'. I think that depends makes more sense, so I'm filing this against trn. Bdale
Bug#1754: #1719
Hyperlatex doesn't recommend ghostscript but gs from 1.3-5 (and higher) I'm closing this bug. -- Erick [EMAIL PROTECTED] +31-10-4635142 Department of General Surgery (Intensive Care) University Hospital Rotterdam NL
Bug#1754: 1719
> > Hyperlatex doesn't recommend ghostscript but gs from 1.3-5 (and higher) > I'm closing this bug. > -- > Erick [EMAIL PROTECTED] +31-10-4635142 > Department of General Surgery (Intensive Care) University Hospital Rotterdam > NL > > Oops this wasn't my intension, forgot BUG in the subject. Trying again. -- Erick [EMAIL PROTECTED] +31-10-4635142 Department of General Surgery (Intensive Care) University Hospital Rotterdam NL
Bug#1756: SEGV in "at" date parsing
Marek Michalkiewicz wrote: >Package: at >Version: 2.8a-2 > >The at command sometimes has problems with date parsing which result >in a SEGV. For example: > >$ at tomorrow >Segmentation fault I think I've fixed this in the most recent version of at, 2.9a, which has been out since August or so. Thomas -- Thomas Kvnig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram.
Packaging guidelines
Since noone is maintaining these, and they *desperately* need updating, I shall do it. Who has the latest version and which format are they in ? Ian.
Bug#1757: Bash doesn't quote correctly
Package: bash
Version: 1.14.4-5
Bash doesn't quote correctly in some cases. Here is a test case which
exhibits the problem:
---start of showbug---
#!/bin/sh
./printargc $0 ${1+"$@"}
---end of showbug---
---start of printargc---
#!/bin/sh
echo 'argc =' $#
---end of printargc---
Running "showbug '1 2'" should result in "argc = 2", but instead results
in "argc = 3".
This bug is fixed in bash-1.14.5. From the NEWS file:
This file documents the bugs fixed between this release, bash-1.14.5,
and the last public bash release, 1.14.4.
1. Bugs fixed in Bash
...
d. Fixes to the expansion code so that double quotes on the rhs of
${variableOPword} are handled better.
This fix is badly needed by some scripts which I run routinely.
David
---
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED] 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Bug#1753: trn recommends, instead of depends
Bdale Garbee writes ("Bug#1753: trn recommends, instead of depends"):
> Package: trn
> Version: 3.6-2
>
> It's not clear to me why trn uses 'recommends' for a mail transport
> and a news article injector, while tin uses 'depends'. I think that depends
> makes more sense, so I'm filing this against trn.
Recommends is correct. You can read news perfectly happily without
either a mail transport or a news article injector.
I'll reassign the bug report to tin.
Ian.
Re: changes file format
Bill Mitchell writes ("changes file format"):
> Just out of curiosity, does the following represent a horribly
> formatted and human-unreadable package announcement? Except for
> the lack of a Priority field, it passes the dchanges(1) syntax check.
I completely fail to understand why anyone is promoting this format.
It is ugly, and my format is machine readable too.
For comparison, below is what that announcement would have looked like
if I'd generated it (assuming priority=medium).
James A. Robinson writes ("Re: changes file format "):
> Very nice! I think it looks quite good.
Are you saying it looks anywhere near as nice as mine ? (Ra ra ra
format wars.) This sounds really childish, I suppose, but there is an
important issue here: having our release announcements and changelog
files look good and be easily readable is important.
Given that both formats are machine-readable and that they have almost
exactly the same content there seems little reason to choose the
uglier of the two.
Oh, and mine would have allowed the maintainer to put some blank lines
in the list of changes, which I think would have helped the
readability too.
> I also happen to like seeing the MD5SUM and file size information.
In my format you can pass the md5sum information to `md5sum -c'.
Ian.
Adduser is a utility to add users and groups to the system.
adduser (1.94-2); priority=MEDIUM
* Makefile: moved symlink creation from postinst/prerm into
the build stage
* debian.postinst, debian.prerm: deleted
* adduser.8: changed documentation for --home feature
* adduser.pl: fixed some file locking races (Bug#1720)
* adduser.pl: create home directory with setgid bit when
using usergroups (Bug#1544)
* adduser.pl: corrected permissions for copies of /etc/skel
files (Bug#1544)
* adduser.pl: run /usr/local/sbin/adduser.local if it exists
(patch for this feature provided in Bug#1544)
* adduser.pl: now always does chown before chmod
(Bug#1544, Bug#1720)
* adduser.pl: now correctly copies dot files from /etc/skel
(Bug#1500)
* adduser.pl: now gives informative message when called from
a non-root user (Bug#1350)
* adduser.pl: enforces that user names are never longer than
8 characters (Bug#1241)
* adduser.pl: now copies everything below /etc/skel (Bug#1542)
-- Sven Rudolph <[EMAIL PROTECTED]> 23 Oct 1995 18:43:31 MET
847dfb732aa3e994f1917d27ffc20eb3 adduser-1.94-2.deb
70fa124c71e5b709019f6729eb8cfe11 adduser-1.94-2.tar.gz
-rw-r--r-- 1 root root13122 Oct 23 18:43 adduser-1.94-2.deb
-rw-rw-r-- 1 root ian 24448 Oct 23 18:43 adduser-1.94-2.tar.gz
Bug#1755: ping -l (preload) works for non-superusers
Package: netbase Version: 1.91-1 See the transcript below. The `-f' (flood ping) option is disabled for non-root users, but IMO the -l option should be restricted or disabled too. Ian. chiark:~> id uid=1001(ijackson) gid=1001(ijackson) groups=1001(ijackson),202(doom),203(killer) chiark:~> ping -l2000 -i3 X [hostname deleted to spare the innocent] PING X.chu.cam.ac.uk (131.111.131.X): 56 data bytes 64 bytes from 131.111.131.X: icmp_seq=0 ttl=255 time=1692.6 ms 64 bytes from 131.111.131.X: icmp_seq=1 ttl=255 time=1696.9 ms 64 bytes from 131.111.131.X: icmp_seq=2 ttl=255 time=1699.2 ms 64 bytes from 131.111.131.X: icmp_seq=3 ttl=255 time=1700.4 ms 64 bytes from 131.111.131.X: icmp_seq=4 ttl=255 time=1700.5 ms 64 bytes from 131.111.131.X: icmp_seq=5 ttl=255 time=1703.1 ms 64 bytes from 131.111.131.X: icmp_seq=6 ttl=255 time=1703.2 ms 64 bytes from 131.111.131.X: icmp_seq=7 ttl=255 time=1704.3 ms 64 bytes from 131.111.131.X: icmp_seq=8 ttl=255 time=1704.5 ms 64 bytes from 131.111.131.X: icmp_seq=9 ttl=255 time=1705.6 ms 64 bytes from 131.111.131.X: icmp_seq=10 ttl=255 time=1705.8 ms 64 bytes from 131.111.131.X: icmp_seq=11 ttl=255 time=1706.9 ms 64 bytes from 131.111.131.X: icmp_seq=12 ttl=255 time=1707.0 ms 64 bytes from 131.111.131.X: icmp_seq=13 ttl=255 time=1708.1 ms 64 bytes from 131.111.131.X: icmp_seq=14 ttl=255 time=1708.3 ms 64 bytes from 131.111.131.X: icmp_seq=15 ttl=255 time=1715.2 ms 64 bytes from 131.111.131.X: icmp_seq=16 ttl=255 time=1715.5 ms 64 bytes from 131.111.131.X: icmp_seq=17 ttl=255 time=1716.7 ms 64 bytes from 131.111.131.X: icmp_seq=18 ttl=255 time=1716.8 ms 64 bytes from 131.111.131.X: icmp_seq=19 ttl=255 time=1717.9 ms 64 bytes from 131.111.131.X: icmp_seq=20 ttl=255 time=1715.6 ms 64 bytes from 131.111.131.X: icmp_seq=21 ttl=255 time=1716.7 ms 64 bytes from 131.111.131.X: icmp_seq=22 ttl=255 time=1716.9 ms 64 bytes from 131.111.131.X: icmp_seq=23 ttl=255 time=1718.0 ms 64 bytes from 131.111.131.X: icmp_seq=24 ttl=255 time=1719.1 ms 64 bytes from 131.111.131.X: icmp_seq=25 ttl=255 time=1720.2 ms 64 bytes from 131.111.131.X: icmp_seq=26 ttl=255 time=1722.0 ms 64 bytes from 131.111.131.X: icmp_seq=27 ttl=255 time=1735.1 ms 64 bytes from 131.111.131.X: icmp_seq=28 ttl=255 time=1735.5 ms 64 bytes from 131.111.131.X: icmp_seq=29 ttl=255 time=1736.6 ms 64 bytes from 131.111.131.X: icmp_seq=30 ttl=255 time=1736.8 ms 64 bytes from 131.111.131.X: icmp_seq=31 ttl=255 time=1737.9 ms 64 bytes from 131.111.131.X: icmp_seq=32 ttl=255 time=1738.1 ms 64 bytes from 131.111.131.X: icmp_seq=33 ttl=255 time=1739.2 ms 64 bytes from 131.111.131.X: icmp_seq=34 ttl=255 time=1739.4 ms 64 bytes from 131.111.131.X: icmp_seq=35 ttl=255 time=1740.5 ms 64 bytes from 131.111.131.X: icmp_seq=36 ttl=255 time=1740.7 ms 64 bytes from 131.111.131.X: icmp_seq=37 ttl=255 time=1741.9 ms 64 bytes from 131.111.131.X: icmp_seq=38 ttl=255 time=1742.0 ms 64 bytes from 131.111.131.X: icmp_seq=39 ttl=255 time=1743.1 ms 64 bytes from 131.111.131.X: icmp_seq=40 ttl=255 time=1743.3 ms 64 bytes from 131.111.131.X: icmp_seq=41 ttl=255 time=1744.4 ms 64 bytes from 131.111.131.X: icmp_seq=42 ttl=255 time=1744.6 ms 64 bytes from 131.111.131.X: icmp_seq=43 ttl=255 time=1756.0 ms 64 bytes from 131.111.131.X: icmp_seq=44 ttl=255 time=1757.9 ms 64 bytes from 131.111.131.X: icmp_seq=45 ttl=255 time=1765.6 ms 64 bytes from 131.111.131.X: icmp_seq=46 ttl=255 time=1765.6 ms 64 bytes from 131.111.131.X: icmp_seq=47 ttl=255 time=1766.7 ms 64 bytes from 131.111.131.X: icmp_seq=48 ttl=255 time=1768.3 ms 64 bytes from 131.111.131.X: icmp_seq=49 ttl=255 time=1769.4 ms 64 bytes from 131.111.131.X: icmp_seq=50 ttl=255 time=1769.5 ms 64 bytes from 131.111.131.X: icmp_seq=51 ttl=255 time=1770.7 ms 64 bytes from 131.111.131.X: icmp_seq=52 ttl=255 time=1770.8 ms 64 bytes from 131.111.131.X: icmp_seq=53 ttl=255 time=1772.0 ms 64 bytes from 131.111.131.X: icmp_seq=54 ttl=255 time=1772.2 ms 64 bytes from 131.111.131.X: icmp_seq=55 ttl=255 time=1773.3 ms 64 bytes from 131.111.131.X: icmp_seq=56 ttl=255 time=1773.4 ms 64 bytes from 131.111.131.X: icmp_seq=57 ttl=255 time=1774.5 ms 64 bytes from 131.111.131.X: icmp_seq=58 ttl=255 time=1774.7 ms 64 bytes from 131.111.131.X: icmp_seq=59 ttl=255 time=1775.8 ms 64 bytes from 131.111.131.X: icmp_seq=60 ttl=255 time=1776.0 ms 64 bytes from 131.111.131.X: icmp_seq=61 ttl=255 time=1777.8 ms 64 bytes from 131.111.131.X: icmp_seq=62 ttl=255 time=1778.0 ms 64 bytes from 131.111.131.X: icmp_seq=63 ttl=255 time=1779.1 ms 64 bytes from 131.111.131.X: icmp_seq=64 ttl=255 time=1779.3 ms 64 bytes from 131.111.131.X: icmp_seq=65 ttl=255 time=1780.4 ms 64 bytes from 131.111.131.X: icmp_seq=66 ttl=255 time=1781.0 ms 64 bytes from 131.111.131.X: ic
Bug#1758: recommended
reassign 1753 tin
Bug#1744: dpkg: cannot scan updates directory `/var/lib/dpkg/updates/': No such file or directory
Here's an strace of dpkg failing. [Remember, this is on an empty
directory.]
Notice especially the line that reads:
readdir(4, 0x48000) = -1 ENOENT (No such file or directory)
I don't have a clue where that 0x48000 argument is coming from, but it
looks like it's corrupt
uselib("/lib/ld.so")= 0
getuid()= 0
geteuid() = 0
getgid()= 0
getegid() = 0
stat("/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=410, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
mmap(0, 410, PROT_READ, MAP_SHARED, 3, 0) = 0x4000
close(3)= 0
uselib("/lib/libc.so.4.6.27") = 0
munmap(0x4000, 410) = 0
munmap(0x62f0, 20480) = 0
brk(0) = 0x2cae4
brk(0x2fae4)= 0x2fae4
brk(0x3)= 0x3
brk(0x31000)= 0x31000
umask(022) = 022
sysinfo({uptime=572, loads=[0, 864, 0] totalram=11497472, freeram=6713344,
sharedram=2146304, bufferram=2777088} totalswap=0, freeswap=0, procs=13}) = 0
getuid()= 0
geteuid() = 0
access("/var/lib/dpkg", W_OK) = 0
open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_TRUNC, 0660) = 3
fcntl(3, F_SETLK, {type=F_EXLCK, whence=SEEK_SET, start=0, len=0}) = 0
brk(0x32000)= 0x32000
brk(0x33000)= 0x33000
open("/var/lib/dpkg/status", O_RDONLY) = 4
read(4, "Package: vim\nStatus: unknown ok"..., 16384) = 16384
brk(0x44000)= 0x44000
brk(0x45000)= 0x45000
brk(0x46000)= 0x46000
read(4, "lled\nPriority: optional\nSectio"..., 16384) = 16384
brk(0x47000)= 0x47000
brk(0x48000)= 0x48000
read(4, "nknown ok not-installed\nPriorit"..., 16384) = 143
read(4, "", 16384) = 0
close(4)= 0
stat("/var/lib/dpkg/updates/", {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
open("/var/lib/dpkg/updates/", O_RDONLY) = 4
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
brk(0x49000)= 0x49000
readdir(4, {d_ino=7740688, d_name="."}) = 1
readdir(4, {d_ino=7740689, d_name=".."}) = 1
readdir(4, 0x48000) = -1 ENOENT (No such file or directory)
close(4)= 0
stat("/etc/locale/C/libc.cat", 0xb950) = -1 ENOENT (No such file or
directory)
stat("/usr/lib/locale/C/libc.cat", 0xb950) = -1 ENOENT (No such file or
directory)
stat("/usr/lib/locale/libc/C/usr/share/locale/C/libc.cat", 0xb950) = -1
ENOENT (No such file or directory)
stat("/usr/local/share/locale/C/libc.cat", 0xb950) = -1 ENOENT (No such
file or directory)
write(2, "dpkg: cannot scan updates direct"..., 88dpkg: cannot scan updates
directory `/var/lib/dpkg/updates/': No such file or directory
) = 88
fcntl(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
_exit(2)= ?
--
Raul
Bug#1759: running out of swap causes deadlock
Package: source Version: 1.2.13 To reproduce: do lots of things that need lots of swap, when you haven't got enough. Effect: system locks up totally, with only an insignificant amount of disk activity. Thrashing badly I could understand (but wouldn't like). Randomly killing processes I could understand, and might at least allow *some* of the system to come down cleanly. As it is, you have to hit the reset switch. This is a known problem with Linux in general. I just thought I'd report it here as we're supposed to be able to have the package maintainer chase up the upstream maintainer - linux-kernel in this case. Usually discussions of this on linux-kernel produce heat but no light. Ian.
Re: Bug#1758: recommended
Ian Jackson writes ("Bug#1758: recommended"):
> reassign 1753 tin
Damn, that's the second time I've done that.
I'll go and check my mail aliases.
Ian.
Overdue problem reports
The following problem reports are very old but have not yet been marked as `taken up' by a message to [EMAIL PROTECTED] or as forwarded to a developer by CCing a message to [EMAIL PROTECTED] Please help ensure that these bugs are dealt with quickly, even if you are not the package maintainer in question. (NB a full list of outstanding bug reports is posted on Fridays - this is a partial list only!) OVER 8 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 379 mount Repeatable mount(1) problem wi Bill Mitchell <[EMAIL PROTECTED] 416 wenglish perl doesn't flush output auto [EMAIL PROTECTED] 421 term unreasonable restriction on te Raul Miller <[EMAIL PROTECTED]> OVER 7 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 563 tartar -x fails to overwrite or c [EMAIL PROTECTED] (Ian Jackso 579 image (?) missing /usr/man/man8 manpages Bill Mitchell <[EMAIL PROTECTED] 660 gdbGDB gets address of structure [EMAIL PROTECTED] (Ian Jackso 662 procps top doesn't behave sensibly if [EMAIL PROTECTED] (Ian Jackso OVER 6 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 691 textutils textutils package, fmt(1) prog Bill Mitchell <[EMAIL PROTECTED] 702 findutils locate crash with large db Ernie Elu <[EMAIL PROTECTED] 710 xs3X server problem with hardware [EMAIL PROTECTED] (Ian Jackso 713 mh mh should pause after printing [EMAIL PROTECTED] (Ian Jackso 723 xconfigX server default configuration [EMAIL PROTECTED] (Ian Jackso 725 xbase twm places windows incorrectly [EMAIL PROTECTED] (Ian Jackso 729 procps Bizarre corrupted output from [EMAIL PROTECTED] (Ian Jackso 731 ncursesncurses wgetnstr doesn't work [EMAIL PROTECTED] (Ian Jackso 737 gawk gawk references to `$0' in END [EMAIL PROTECTED] (Ian Jackso 740 xbase xclock leaves `droppings' in i Ian Jackson <[EMAIL PROTECTED] 746 cpio mt doesn't support setblk (and [EMAIL PROTECTED] (Ian Jackso 759 kbd, xbase /usr/bin/X11/showfont conflict [EMAIL PROTECTED] (Raul Miller) 773 xbase xmh falls over if mh is not in [EMAIL PROTECTED] (Richard K 775 xbase twm reports errors on incorrec [EMAIL PROTECTED] (Richard K 783 tartar --same-order doesn't work [EMAIL PROTECTED] (Ian Jackso 784 manpages Infelicities in fopen manpage [EMAIL PROTECTED] (Ian Jackso 785 cpio mt problems[EMAIL PROTECTED] (Bill 786 syslogdsyslogd gone awol [EMAIL PROTECTED] (Ian Jacks 797 (base) /etc/termcap console keydefs f Bill Mitchell <[EMAIL PROTECTED] 798 svgalibsvgalib gets control key mucke [EMAIL PROTECTED] (Raul Miller) 808 emacs Info anchors not active in ema [EMAIL PROTECTED] 817 tartar -T /dev/null extracts whol [EMAIL PROTECTED] (Ian Jackso 818 bash bash builtin `echo' doesn't ch [EMAIL PROTECTED] (Ian Jackso 819 tartar should have null-separated [EMAIL PROTECTED] (Ian Jackso 820 tcsh tcsh builtin `echo' doesn't ch [EMAIL PROTECTED] (Ian Jackso 821 shellutils /bin/echo doesn't check write [EMAIL PROTECTED] (Ian Jackso 822 tartar -t doesn't check write err [EMAIL PROTECTED] (Ian Jackso 824 cpio cpio should have non-verbose, [EMAIL PROTECTED] (Ian Jackso 825 trntrn warning messages corrupt t [EMAIL PROTECTED] (Ian Jackso 827 libc or sh who reports wrong hostname (wa [EMAIL PROTECTED] (Christian 835 sysklogd syslogd dies, leaves system un [EMAIL PROTECTED] (William 836 (base) Possible bugs in termcap syste "Emilio C. Lopes" <[EMAIL PROTECTED] OVER 5 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 841 ncursesdselect from dpkg 0.93.34 says [EMAIL PROTECTED] (Bill 844 manpages readdir(3) should document str [EMAIL PROTECTED] (Ian Jackso 845 manpages access(2) is ambiguous [EMAIL PROTECTED] (Ian Jackso 850 indent [indent] option mentioned in d [EMAIL PROTECTED] (J.H.M 853 shellutils `nice' does not do anything[EMAIL PROTECTED] (Ian Jackso 857 gs_bothgs (2.6.1pl4-4) doesn't use /e [EMAIL PROTECTED] (Ian Jackso 860 mount `only root can mount' can mean [EMAIL PROTECTED] (Ian Jackso 864 make make gets MAKEFLAGS wrong [EMAIL PROTECTED] (Ian Jackso 887 xarchieR6 xarchie barfs when ftp closes [EMAIL PROTECTED] 889 info Info 3.1-6 [EMAIL PROTECTED] (Emilio C. 902 lprlpr can't print a PostScript f [EMAIL PROTECTED] (Ian Jackso 903 (base) /dev miscellaney Bill Mitchell <[EMAIL PROTECTED] 911 libc libc causes rsh to fail on com [EMAIL PROTECTED] (Ian Jackso 918 miscutils mkboot and image packages [EMAIL PROTECTED] (Bill OVER 4 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject
Re: changes file format
[EMAIL PROTECTED] said: > Are you saying it looks anywhere near as nice as mine ? Well, I think it looks awful, but I will accept your format simply to end this argument if you or someone else will write and maintain the parser for it and an automated tool to generate it. I don't see how you could seriously propose a context-dependent parse, but I'm sick of the argument. Bruce
Re: changes file format
On Tue, 24 Oct 1995, Bruce Perens wrote: > [EMAIL PROTECTED] said: > > Are you saying it looks anywhere near as nice as mine ? > > Well, I think it looks awful, but I will accept your format simply > to end this argument if you or someone else > will write and maintain the parser for it and > an automated tool to generate it. Please add "and document" to this. If tools are introduced into the distribution, the author and maintainer of those tools should provide and maintain man pages for them. > I don't see how you could seriously propose a context-dependent parse, but > I'm sick of the argument. Me too. I also reiterate my suggestion that we stop the practice of maintainers announcing directly (and prematurely) to debian-changes, and have the maintainer announcements uploaded to debian.org along with the other package files, machine-parsed there, and machine-produced announcements in whatever announcement format is deemed appropriate incorporating information from the machine-parsed maintainer uploads made from debian.org once the packages being announced are actually available as part of the distribution.
Re: bc-1.03-8 uploaded
Bill Mitchell writes ("bc-1.03-8 uploaded"):
> added /usr/doc/dc with dc.texinfo man Makefile
Bill Mitchell writes ("sharutils-4.1-7 uploaded"):
> Changes: Added texinfo file and Makefile to /usr/doc/sharutils
Bill Mitchell writes ("indent-1.9.1-12 uploaded"):
> Changes: Added texinfo file and Makefile in /usr/doc/indent
Bill Mitchell writes ("diff-2.7-5 uploaded"):
> Changes: Added texinfo file and Makefile in /usr/doc/diff
Why ? The texinfo file is a piece of source code and belongs in the
source package.
The convention with all the other packages is to put the generated
info file in /usr/doc/info.
I think that if we want to distribute any other format we should put
the formatted version in /usr/doc.
In any case, it seems very unwise to put effort into changing all your
packages in line with some new policy without first discussing whether
the policy is a good one ...
Ian.
Re: Conflicting with a range of revisions...
Michael Alan Dorman writes ("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.
`|' is not allowed in conflicts; `,' is used to mean OR.
What you wrote was equivalent to
"this package conflicts with minicom (versions 1.71-2 and earlier),
and it also conficts with minicom (versions 1.6 and later)."
Clearly this covers all versions of minicom.
There is no way to express `conflicts with versions nn to mm'. If you
really need it you could list the versions explicitly, but I'd be
inclined just to say
Conflicts: minicom (<1.71-2)
Ian.
Re: changes file format
[EMAIL PROTECTED] said: > Please add "and document" to this. If tools are introduced into the > distribution, the author and maintainer of those tools should provide > and maintain man pages for them. Yes, that makes sense. The parse wasn't immediately obvious to me. For example, is the semicolon significant? An explanation of the format, as well as the use of the tools, is called for. [EMAIL PROTECTED] said: > I also reiterate my suggestion that we stop the practice of > maintainers announcing directly (and prematurely) to debian-changes, > and have the maintainer announcements uploaded to debian.org along > with the other package files, machine-parsed there, and > machine-produced announcements in whatever announcement format is > deemed appropriate incorporating information from the machine-parsed > maintainer uploads made from debian.org once the packages being > announced are actually available as part of the distribution. This is why I require both a parser and a program to generate the input. Because the format _looks_ free-form, there is less "psychological pressure" to format the document with a machine parse in mind. Once this parser is provided, we will make a script for the FTP maintainer to run that will move the package into place and announce the upload to debian-changes. Thanks Bruce
Re: changes file format
> I completely fail to understand why anyone is promoting this format. > > It is ugly, and my format is machine readable too. But Ian, almost _any_ format can be made machine readable -- but Bill's format is _easily_ machine readable -- you could slap together a whole bunch of ways to read it. I'm very much against going all out for "beauty" when you can have a nice compromise between beauty and easy functionality. I just had to deal with such a problem with our people who make up the Faculty and Staff directory at my school. They _insist_ on making it in Word. So I get very nice looking ascii text: Jim RobinsonLibrary 371 Network Administrator Network, Room 6 The Cottage Simon's Rock College Great Barrington, MA 01230 528-8150 That is an absolute nightmare to pull apart -- the second "column" format is constantly changing, as is the little "extras" they add for people with more then one phone: "334 Tue, 320 Mon-Fri" in the phone section, and so on! Compare to: Jim Robinson (jimr): Network Administrator Networking Office. Phone: (413) 528-7371 Fax: (413) 528-7380 Internet mail: [EMAIL PROTECTED] Now, the information content is slightly different, but I find the latter just as "readable" if not as pretty. The latter format is also much easier to pull apart with code. > Are you saying it looks anywhere near as nice as mine ? (Ra ra ra > format wars.) This sounds really childish, I suppose, but there is an > important issue here: having our release announcements and changelog > files look good and be easily readable is important. > > Given that both formats are machine-readable and that they have almost > exactly the same content there seems little reason to choose the > uglier of the two. Hmm, in perl your format is easy to pull apart, in his, perl, awk, and cut could do it with no problem. I don't know -- I just squirm at having to deal with database like information without keys. I usually want to do things with database like information, and if I have to write a context-dependent parser, it gets irritating. > > I also happen to like seeing the MD5SUM and file size information. > > In my format you can pass the md5sum information to `md5sum -c'. To check it? That is nice. Perhaps you two can merge formats -- somehow get a "key" field in there? Let's stop bickering, and start trying to really help one another. This is getting as tiresome to watch as the Matt/Ian/Stephen/ wars. Jim
Re: sysklogd-1.2-13 released
Martin Schulze writes ("sysklogd-1.2-13 released"):
> I'm just trying to upload this package. The changes are only minor
> ones. Here are the relevant ChangeLog entries
>
> ...
> * changed the name in control file (Bug#1695)
Aaargh, no !
Please, change it back.
Ian Murdock wrote:
> * The name of the package appears to have been changed to "sysklogd",
> but the control file still says "syslogd", and the package is still
> referenced via dpkg as "syslogd". If the package name has actually
> changed, it should be changed in the control file, and it should
> also declare a conflict with "syslogd". I'm not convinced changing
> the name is a good idea, but this is the correct procedure for doing
> it.
Changing the name is indeed not a good idea. My network connection is
dead at the moment, so I can't download the package, but there are
likely at least to be some problems with conffiles which may cause
people's changes to their conffiles to be lost.
Package names should not be changed without a good reason.
Ian M.: please do not move this release into the public area.
Ian.
Re: Conflicting with a range of revisions...
> "Ian" == Ian Jackson <[EMAIL PROTECTED]> writes: Ian> `|' is not allowed in conflicts; `,' is used to mean OR. It would be nice if CONFLICTS and the other fields used the same notation for OR/AND, instead of being in direct apposition. Could the current behavior be gradually phased out at some point, or is there some special significance to the comma such that CONFILCTS must use it? Ian> There is no way to express `conflicts with versions nn to Ian> mm'. If you really need it you could list the versions Ian> explicitly, but I'd be inclined just to say Conflicts: Ian> minicom (<1.71-2) That was what I did. I just wanted to see if I was missing something obvious. Mike.
Re: changes file format
Ian Jackson writes:
>Bill Mitchell writes ("changes file format"):
>> Just out of curiosity, does the following represent a horribly
>> formatted and human-unreadable package announcement? Except for
>> the lack of a Priority field, it passes the dchanges(1) syntax check.
>
>I completely fail to understand why anyone is promoting this format.
>It is ugly,
make it tabular
>and my format is machine readable too.
Given the medium we are using that's a tautology :)
>847dfb732aa3e994f1917d27ffc20eb3 adduser-1.94-2.deb
>70fa124c71e5b709019f6729eb8cfe11 adduser-1.94-2.tar.gz
>-rw-r--r-- 1 root root13122 Oct 23 18:43 adduser-1.94-2.deb
>-rw-rw-r-- 1 root ian 24448 Oct 23 18:43 adduser-1.94-2.tar.gz
^
File permissions, link count, ownership an modification times on the
maintainer's system are not of general interest, why include them in an
announcement? The rest easily fits onto a single line and put the fixed length
parts in front.
# md5sum size name
70fa124c71e5b709019f6729eb8cfe11 24448 adduser-1.94-2.tar.gz
847dfb732aa3e994f1917d27ffc20eb3 13122 adduser-1.94-2.deb
With fixed length fields the dchanges format will yield a nice readable table
and a trivial pipe (left as an exercise to the reader) lets you check the
md5sum.
'nuf said
-- Siggy (the middle S.)
Re: changes file format
On Tue, 24 Oct 1995, James A. Robinson wrote: > But Ian, almost _any_ format can be made machine readable -- but > Bill's format is _easily_ machine readable -- you could slap together > a whole bunch of ways to read it. I'm very much against going all out > for "beauty" when you can have a nice compromise between beauty and > easy functionality. I'd intended to drop this topic, but I'll belabor one point here. If package announcements are uploaded to debian.org for machine parsing and debian-changes announcements are machine-generated from there, The mechanized debian-changes announcement generator has a lot of control over the aesthetics of the announcement format which is presented to humans for reading.
